Programme d'informatique élémentaire

De April MediaWiki
Version datée du 4 juillet 2009 à 18:02 par Odile (discussion | contributions) (→‎La rédaction de texte : Version de Patrice)
Aller à la navigationAller à la recherche

Cette page recueille une ébauche de programme d'informatique pour les écoles primaires et secondaires.

Dans un premier temps, l'effort consiste à rassembler des énoncés de connaissances ou compétences que nous voudrions voir enseignées, et de les classer par thèmes (chapitres). Ce travail nous fournira une grille d'analyse des contenus.

Dans un second temps, nous essaierons de déterminer plus précisément le niveau / âge idéal pour chaque contenu.


Programme d'informatique élémentaire

NB : Cette structuration est une proposition. D'autres propositions peuvent être envisagées et même faire l'objet d'une nouvelle page. Le débat doit rester ouvert à ce stade.

Le courrier électronique

Faire face aux problèmes liés à l'encodage

Il n'est pas rare de recevoir des messages électroniques présentant des erreurs relatives à l'encodage des caractères : courriers en UTF-8 annoncé par les headers en iso-8859-1 et donc mal affichés par le MUA, surcodage défectueux du corps ou du sujet, … Les utilisateurs restent souvent démunis face à ces problèmes alors qu'il leur est facile, au moins pour les charsets, de régler manuellement leur logiciel pour obtenir un affichage normal.

  • Je sais quels réglages de mon logiciel de courrier électronique je dois modifier pour lire correctement les caractères accentués quand je reçois un courriel dans lesquels ceux-ci sont remplacés par des caractères anormaux.
  • [ détail ] Dans le même cas de figure, je ne trouve plus ces caractères bizarres, je peux expliquer exactement la situation et je sais exactement quel réglage précis faire pour avoir un affichage correct.

Gérer les pièces jointes

L'utilisateur doit transmettre des informations par courrier électronique.

  • il sait quels formats de données sont adéquats pour transmettre ces données (il n'envoie par exemple pas un mail de trois lignes dans une pièce jointe au format traitement de texte - je peux fournir des exemples)
  • il sait que certains formats risquent de poser des problèmes d'interopérabilité.

L'utilisateur reçoit un courrier électronique avec une pièce jointe qu'il n'arrive pas à ouvrir :

  • le fichier n'a pas d'extension et le système refuse de faire autre chose que de demander à l'utilisateur ce qu'il doit faire de ce fichier,
  • l'extension du fichier est fautive est fautive (un document PDF est envoyé avec une extension .doc),
  • l'extension est contredite par le Content-Type,
  • l'extension est bonne mais le Content-Type est application/stream,

L'utilisateur doit retransmettre (forwarder) un message électronique, éventuellement avec des pièces jointes.

  • Je sais quel format de données est le mieux adapté pour transmettre des informations textuelles : message électronique simple, pièce jointe dans un format bureautique, au format HTML
  • Je connais les principes de la netiquette et je n'envoie de message au format HTML que si c'est la solution vraiment la plus adaptée
  • Je sais que mes correspondants ne possèdent pas forcément les mêmes logiciels que moi, ou pas dans la même version, et je sais donc choisir les formats de mes données qui garantissent la plus grande interopérabilité
  • Je connais les différents mécanismes qui commandent à l'ouverture automatique des pièces jointes lorsque je clique dessus (utilisation de l'extension et de la base mailcap ou équivalent, utilisation du champ Content-Type)
  • Je sais enregistrer une pièce jointe à l'extérieur de mon logiciel de courrier électronique lorsque je n'arrive pas à l'ouvrir automatiquement
  • Je sais examiner le source du message pour essayer de trouver le type d'une pièce jointe dont l'extension est mauvaise ou non spécifiée
  • Je sais, en fonction du format d'un message, si je dois le transférer en ligne ou en pièce jointe [peut-être à mettre ailleurs]

Discriminer certains spams des vrais messages d'erreurs et exploitation de ces derniers

Les messages d'erreurs renvoyés par les serveurs de courriers électroniques souffrent de trois défauts : ils sont rédigés en anglais (et ceci ne changera sans doute pas de sitôt), leur formalisme rend leur compréhension difficile : l'information pertinente n'apparait pas toujours au premier coup d'œil) et depuis quelques années les spammeurs ont trouvé le moyen de les utiliser pour propager leur pourriels. Ce dernier défaut fait que souvent ces messages sont tout bonnement considérés systématiquement comme du spam par les utilisateurs non avertis. Pourtant ces messages continuent à être le seul moyen d'être informé d'une erreur au cours de la transmission d'un message électronique. Il importe donc que les utilisateurs sachent faire la différence entre les messages d'erreur provoqués par les spammeurs et les messages d'erreur authentiques et sachent d'autre part exploiter le contenu de ces derniers pour mettre en œuvre les mesures qui s'imposent alors :

  • renvoi du message à une adresse corrigée,
  • prise de contact par un autre moyen lors d'un dépassement de quota,
  • prise de contact par un autre moyen encore lors d'un problème transitoire si le contact est urgent,

Procédure de test

Présenter à l'élève une liste de courriers préparés (sans doute prélevés dans une boîte réelle et juste modifiés pour qu'ils soient plus faciles à contextualiser) représentants les cas de figure les plus courants : adresse incorrecte (deux types), bounce provoqué par un spammeur, dépassement de quota, délivrance retardée, …

Compétences

  • Quand j'ai des courriers signés Mail Delivery System ou Mailer Daemon je sais ce qu'il faut faire pour savoir s'il s'agit d'une vraie erreur ou d'un spam.
  • Je suis capable de comprendre les principaux messages d'erreurs des serveurs de courrier électroniques et je sais comment réagir si nécessaire

Évaluer le degré d'authenticité d'un message

Depuis la simple farce faite par des collègues (mais dont les conséquences peuvent être facheuses si ceux-ci n'assurent pas un suivi permanent) jusqu'à la véritable tentative de hameçonnage, l'éventail des cas pour lesquels un examen au moins sommaire des en-têtes complets d'un message peut être profitable est large. Voir aussi le groupe d'items suivant sur les courriels signés et chiffrés.

  • Je sais que la signature apparente d'un message ne garantit en rien l'authenticité d'un message
  • Je sais examiner les en-têtes complets d'un message afin d'évaluer le degré d'authenticité d'un message

Gérer les courriels signés et chiffrés

La compétence sans doute la moins partagée et pourtant d'une importance sans cesse grandissante dans un univers où les pouvoirs économiques et politiques n'hésitent plus à rogner au moindre prétexte sur les droits de l'homme. À titre personnel j'avoue ne pas avoir encore rencontré d'utilisateur non informaticien qui utilise ni même sache utiliser les techniques de signature et de chiffrement des courriers électroniques et pour une fois je ne peux donc proposer de cas d'usage véritable : juste un constat de la permanence des cas de non-usage. Il est vrai que les concepts sous-jacents ne sont pas triviaux (je ne parle même pas des systèmes de cryptographie, juste des principes généraux mis en œuvre : paires de clefs publiques/privées, certificats et tiers de confiance, …) et repoussent sans doute cet apprentissage à la fin du second cycle, pour autant je ne pense pas que l'on puisse aujourd'hui prétendre avoir délivré une formation en éducation civique si l'on n'a pas formé l'élève à la compréhension des concepts généraux et à l'utilisation des outils de signature et de chiffrement.

  • Je sais expliquer la différence entre un message signé et un message chiffré.
  • Je connais les principes des méthodes mises en œuvre pour chiffrer et signer des messages électroniques
  • Je comprends la différence entre un authentification par certificat et une authentification par clef publique
  • Je sais ce qu'est une autorité de certification
  • Je connais au moins une procédure pour générer une paire de clef publique / clef privée
  • Je suis capable de nommer quelques organismes publiques ou privés (payants et gratuits) faisant office d'autorités de certification

Se protéger contre les spams

  • Je connais les méthodes qui me permettent d'examiner le contenu d'un message électronique suspect sans prendre de risque.
  • Je sais que les spams ne sont pas, en tant que tel, des virus
  • Je sais que les images contenues dans un message électronique peuvent être soit jointes au message, soit référencées par des liens
  • je sais que je dois configurer mon lecteur de courriel pour qu'il ne charge pas les images non incluses dans les messages
  • Je sais que je ne dois pas cliquer sur les liens figurant dans un spams
  • Je sais, si j'ai un doute sur la nature d'un message, examiner son code source afin de déceler d'éventuels faux liens
  • Je connais les principes de fonctionnement des logiciels antispams
  • Je sais ce qu'est un faux-positif pour un logiciel antispam
  • Je sais que des logiciels antispams peuvent être installés chez mon fournisseur d'accès à Internet, sur mon ordinateur ou intégré dans mon logiciel de courrier et je comprends les avantages et inconvénients de chacune de ces méthodes
  • Je sais qu'il faut régulièrement vérifier les messages détectés comme spams pour voir s'il n'y a pas parmi eux de faux-positifs
  • Je sais qu'il faut faire montre de la plus grande prudence avant de donner mon adresse de courrier électronique sur un site web, par exemple sur un forum [lien avec les compétences les compétences sur le Web] ou un blog

Se protéger contre les virus transmis par le courrier électronique

Le courrier électronique constitue indéniablement l'un des vecteurs d'attaque les plus puissants pour les créateurs de virus informatique. Lorsque la charge virale est utilisée pour inclure la machine infectée dans un botnet cette machine devient potentiellement la source des deux principales plaies du courrier électroniques : le spam et les virus. En dépit des avertissements permanents tant des utilisateurs avertis, des éditeurs que des médias, y compris grand public, qui n'a pas eu dans son entourage un collègue ou un ami ou n'a pas été soi-même victime d'un virus transmis par le courrier électronique ?

Compétences

  • Je connais les méthodes qui me permettent d'examiner le contenu d'un message électronique suspect sans prendre de risque.
  • Je sais qu'il faut régler mon logiciel de courrier électronique pour qu'il ne provoque jamais l'exécution du code exécutable contenu dans une pièce jointe
  • Je sais que l'extension d'une pièce jointe peut-être modifiée pour masquer la nature véritable du fichier
  • Je sais que même si l'adresse de l'expéditeur d'un message m'est familière il me faut néanmoins exercer la plus grande prudence avec les pièces jointes.
  • Je sais que les fichiers bureautiques peuvent aussi contenir des bouts de programmes appelés macros et qu'ils peuvent donc être porteurs de virus
  • Je sais qu'il faut systématiquement interdire l'exécution automatique des macros dans mes logiciels bureautiques. [lien avec les rubriques “bureautiques”]

Se protéger contre le hameçonnage

  • Je connais les méthodes qui me permettent d'examiner le contenu d'un message électronique suspect sans prendre de risque.
  • Je sais, si j'ai un doute sur la nature d'un message, examiner son code source afin de déceler d'éventuels faux liens
  • je sais ce que signifie le terme ingénierie sociale

Connaissance des principes généraux du courrier électronique

À la base de toutes les difficultés potentielles énumérées plus haut se trouve souvent une méconnaissance profonde des mécanismes de base du courrier électronique : les modèle client-serveur à l'envoi, à la consultation (et les avantages et inconvénients des différents protocoles et interfaces : IMAP, POP, webmails, …), la structuration d'un courrier électronique (en-têtes et corps, pièces jointes, différence entre from de l'enveloppe et from des en-têtes, …), les relais possibles et les mécanismes de protection (RBL, grey-listing, …), etc. S'il n'est bien évidemmet ni envisageable ni utile de connaître le détail des normes et standards sur ces questions, l'aisance dans la manipulation du courrier électronique ne peut naître que d'une compréhension globale des mécanismes et des ressources mis en œuvre pour la transmission du courrier électronique.

Compétences

  • Je sais, sur chacun des ordinateurs que j'utilise, quelle méthode employer pour gérer mon courrier électronique : compte POP ou IMAP, consultation par un webmail, …

La navigation sur Internet

Connaissance des principes généraux de fonctionnement du protocole HTTP et des protocoles associés

« Ça marche pas, j'arrive pas à me connecter ! ». Combien de fois peut-on entendre cette phrase à longueur de journée sur son lieu de travail ou à son domicile ! La connaissance des principes généraux des protocoles réseau impliqués dans un échange requête/réponse HTTP permet pourtant, sinon de résoudre tous les problèmes, au moins de les identifier et d'identifier les acteurs à alerter.

Compétences

Je sais diagnostiquer les raisons les plus courantes qui peuvent empêcher le chargement d'une page web : connexion réseau coupée, problème de résolution DNS, serveur en panne et je sais éventuellement quelle personne ou quel service alerter (FIXME: à détailler).

Capacité à gérer les messages d'erreur communs

« Qu'est-ce que ça veut dire ce message ? J'y comprends rien ? ». Même lorsqu'ils sont en français (ce qui est loin d'être toujours le cas), les messages produits par les navigateurs ou les applications web ne sont pas toujours d'une grande limpidité pour le non-initié. Même l'erreur 404 (et ses deux sources possibles) est encore largement ignorée. Pourtant, l'ignorance de certains messages peut quelquefois mener à des conséquences fâcheuses, comme dans le cas d'une resoumission de données POST.

Procédures de test

Pour les erreurs 404, Un cas assez typique d'URL fautive se trouve lorsqu'une URL est repliée et donc tronquée dans un courriel. On pourra donc proposer aux élèves une telle URL afin de juger de leur capacité à vérifier la source à la recherche de l'erreur.

Le professeur envoie aux élèves un mail comportant une URL mal orthographiée dans son composant terminal (par ex. tecnologie.html au lieu de technolgie.html) et vérifier que l'élève est capable de repérer et corriger cette faute.

Le professeur envoie aux élèves un mail comportant une URL erronée dans son composant terminal (mais cette fois-ci sans que l'erreur soit décelable) mais accompagnée d'un petit texte décrivant le contenu de la ressource. le but est ici de tester la capacité de l'élève à modifier manuellement l'URL pour remonter à l'élément supérieur du path afin d'afficher la page “mère” sur laquelle l'élève pourra retrouver le lien vers la bonne ressource au travers de sa description.

Compétences

  • Je sais distinguer les messages d'erreurs les plus communs du navigateur, de ceux du serveur web ou de ceux de l'application web.
  • Je comprends la signification du message suivant, présenté par mon navigateur après que j'ai cliqué sur le bouton Précédent : « Voulez-vous soumettre à nouveau les données du formulaire ? » et je sais agir en conséquence (FIXME: retrouver le texte exact du message).
  • Je sais que lorsque le serveur ou l'application web m'indique que la page n'existe pas il peut s'agir d'une erreur dans le lien.
  • Je sais comment modifier manuellement une URL aboutissant sur une erreur 404 afin de tenter de parvenir à la ressource si celle-ci existe bien.

La rédaction de texte

Utilisation du traitement de texte


Règles typographiques de base

Polices et interopérabilité

Styles vs. attributs

Les images numériques

La gestion des fichiers

Les principes généraux des réseaux informatiques