L’équipe d’OpenHatch organise régulièrement des rencontres, ateliers, événements, sprints, hackathons, etc. invitant de nouveaux contributeurs à participer au développement de logiciels libres. Elle nous livre ici le fruit de son expérience.

L’enthousiasme et la motivation sont indispensables mais ne peuvent faire l’économie d’une solide organisation et réflexion en amont. Happy Hacking 🙂

Note : On remarquera que les deux livres cités en référence pour aller plus loin font partie de nos traduction Framabook : Libres conseils et Produire du logiciel libre.

 

 

Le guide de l’événement libre in situ

The In-Person Event Handbook

L’équipe OpenHatch – février 2014
(Traduction : Omegax, zak, François, Ju, MrTino, Wan, Asta, François, goofy, amha)

Faire en sorte que votre projet soit prêt pour de nouveaux contributeurs

Il semble que chaque jour apparaisse un nouvel atelier, hackaton ou autre sprint, où des projets open source sont invités à travailler avec de nouveaux contributeurs. À OpenHatch, nous avons nous-mêmes souvent organisé ce genre d’événements ! Nous avons découvert que pour en tirer un profit maximal, il est important de planifier les choses en amont. Expliquer vos objectifs, identifier les tâches appropriées, et tester l’organisation de votre projet sont autant de points indispensables pour aboutir à de belles réalisations et passer un bon moment. Ce travail a grandement amélioré nos expériences, et nous pensons qu’il mérite l’effort significatif qu’il mplique.

Nous avons créé ce guide pour aider les projets open source à se préparer pour ces événements. Nous avons utilisé notre propre projet, l’application web OpenHatch.org, comme un exemple dans ce qui suit. Au bas de la page, vous trouverez des aide-mémoires. Elles contiennent en condensé les conseils dispensés dans ce guide, et peuvent vous aider à monitorer vos progrès durant la phase de préparation de votre projet.

Les sources de ce guide sont libres. Un tas de merci à nos contributeurs. (Vous pouvez contribuer, vous aussi !)

Définir des objectifs

Vous devez être capable de présenter clairement vos objectifs pour l’événement, car cela donne à votre groupe une ambition générale à atteindre. Vous pouvez donc commencer par vous demander :

Quel est l’objectif global de votre projet ?

Il vous faut une réponse courte (un paragraphe ou moins) à cette question que vous pourrez utiliser pour attirer les contributeurs potentiels vers votre projet. Les détails, c’est bien joli, mais vous ne devriez pas avoir besoin d’être trop technique à ce moment là. À de nombreux événements, comme les sprints PyCon, on vous demandera un court résumé à exposer devant tout le monde. Pourquoi ne pas vous y préparer ?

Exemple :

L’objectif de OpenHatch est de rendre les communautés de logiciels libres plus accueillantes pour les nouveaux venus. Pour ce faire, nous fournissons documents et support logistique pour animer des ateliers « Introduction à l’open source », un site web avec des ressources libres, des « missions d’entraînement », un découvreur de talents parmi les bénévoles, et plusieurs autres projets en cours de réalisation.

Que voulez-vous accomplir à cet événement ?

Réfléchissez à ce que vous souhaitez voir spécifiquement réalisé lors de cet événement. Vous pouvez catégoriser ces objectifs selon les différentes parties du projet, si vous en avez plusieurs. Il devrait être spécifié clairement de quelle manière ces actions contribueront au progrès général du projet. Toutefois, il ne s’agit pas de « tâches » — il devrait être toujours nécessaire de diviser ces objectifs pour mieux les atteindre.

Il est utile de les lister en termes d’objectifs « principaux » et « étendus ». Avoir des objectifs principaux réalistes et bien définis vous donne quelque chose à célébrer à la fin de l’événement, tandis que les objectifs étendus ou secondaires vous permettent de prévoir le cas excitant où vous vous retrouviez avec une équipe nombreuse et efficace, capable d’accomplir une tonne de travail.

En général, il vaut mieux avoir trop d’objectifs que pas assez, mais priorisez-les. Lorsque vous arriverez à l’étape du découpage en tâches, prenez le temps de traiter en détail chaque objectif avant de passer au suivant.

Exemple :

• Faire une nouvelle mission d’entraînement
  • Objectif principal : Choisir une compétence sur laquelle baser une nouvelle mission d’entraînement, et concevoir cette mission. En créer une maquette.
  • Objectif étendu : Implémenter la maquette et la faire tester par des volontaires de l’événement.
• Faire le ménage dans le suivi de tickets
  • Objectif principal : Passer en revue l’outil de suivi, et étiqueter les tickets selon le « ménage » à y faire. Un bug doit-il être vérifié ? Un patch doit-il être testé ? Une demande de fonctionnalité doit-elle être être rattachée à un jalon ?
  • Objectif étendu : Utiliser ces étiquettes comme guide pour « faire le ménage » . Vérifier les bugs, tester les patches, etc.

Installation du projet

Dans notre expérience, la phase d’installation du projet est l’obstacle majeur à la participation. Nous avons vu (et conduit !) des événements où les participants passaient le plus clair de leur temps à seulement mettre en place leur environnement de développement et faire connaissance avec le projet. Si notre objectif est de permettre à de nouveaux venus de contribuer, tâchez d’estimer le temps qu’il faut pour installer votre projet. Puis trouvez un ami qui n’est pas familier avec votre projet pour voir combien de temps il faut vraiment. Vous pouvez aussi trouver quelqu’un pour vous aider à faire cela dans #openhatch.

Documenter et améliorer le processus à l’avance peut faire économiser du temps et de l’énergie à tout le monde. Si vous savez qu’une partie de votre projet sera inévitablement dévoreuse de temps, assurez-vous que tous les participants savent exactement à quoi s’en tenir.

Toutes les informations ci-dessous devraient être documentées dans un fichier LISEZ-MOI placé à la racine de votre dépôt. Vous pouvez également placer cette information dans une section « Vous voulez participer ? » sur le site web de votre projet, et/ou vous pouvez inclure un lien vers le LISEZ-MOI dans la signature de votre liste de diffusion ou dans la barre de statut de votre canal IRC.

Comment trouver une communauté et des mainteneurs pour le projet

Les informations des contacts devraient être explicitement affichées, étant donné que vous pourriez avoir des contributeurs éloignés ou des contributeurs qui voudraient démarrer en amont de l’événement. Les types d’informations de contacts peuvent inclure :

• Un lien vers votre mailing-list ;
• Votre nom de canal et de serveur IRC (avec le lien vers le guide pour installer IRC et le lien vers sa version webchat) ;
• Les comptes de réseaux sociaux tels que Identi.ca, Twitter ou Facebook si votre projet en possède ;
• Le contact des mainteneurs du projet, si vous vous sentez à l’aise pour le mentionner.

Si vous avez une préférence pour le type de prise de contact, précisez-le.

Exemple:

OpenHatch laisse en deux endroits des informations de contact que nous essayons le plus possible de garder à jour et en cohérence l’un avec l’autre. Il y a nos informations de contacts dans la documentation, référencées principalement depuis notre répertoire où sont déposés les codes sources, et nos informations de contacts dans le wiki, référencées à partir de la page d’accueil du site web.

La structure du projet

Décrivez la structure de base de votre projet. Quels sont les plus gros composants et où sont-ils situés ? Comment ces composants interagissent-ils ? Puis décomposez chaque partie. Vous n’avez pas à parler de chaque fichier ou sous-dossier de votre projet, mais prenez soin de ne pas prendre pour acquis que chaque nouveau venu comprendra le sens de tel script, ou la manière dont interagissent tels fichiers, ou dans quel langage est programmée telle partie du projet.

Selon la taille et la complexité de votre projet, cela peut être une tâche particulièrement imposante. Chez OpenHatch, nous travaillons toujours à documenter la structure complète du projet. Nous recommandons de commencer par une explication « en vue d’ensemble » de la structure projet – juste assez de détails pour remplir d’une demi-page à une page. Quand vous aurez plus de temps, vous pourrez rentrer dans le détail, en commençant par les parties du projet sur lesquelles les gens travaillent le plus souvent (ou qui sont plus susceptibles de faire l’objet de sprints ou de hackatons). Si vous utilisez d’autres frameworks ou librairies, vous pouvez gagner du temps en mettant des liens vers leur documentation et leurs tutoriels.

Exemple :

Une description d’ensemble de la structure du projet OpenHatch peut être trouvée dans « Project Overview ». Une description de la structure de OH-Mainline (le dépôt derrière notre site web) y est présente.

Comment mettre en place un environnement (« de développement ») local

Pour contribuer à votre projet, les gens ont généralement besoin d’une version locale du projet où ils peuvent faire des modifications et les évaluer. Plus votre guide d’installation/développement est détaillé et clair, mieux c’est.

Voici quelques éléments pour la mise en place d’un environnement de développement à mettre dans votre guide :

• Préparer leur ordinateur
  • Assurez vous qu’ils connaissent bien les outils de leurs systèmes d’exploitation, comme le terminal / la ligne de commande. Vous pouvez le faire en donnant un lien vers un didacticiel et en demandant aux utilisateurs s’ils le comprennent bien. Souvent, de très bons didacticiels existent déjà, celui d’OpenHatch sur la ligne de commande est disponible ici.
  • Si les contributeurs doivent mettre en place un environnement virtualisé, accéder à une machine virtuelle ou installer un kit de développement en particulier, expliquez-leur comment faire.
  • Donnez la liste de toutes les dépendances nécessaires pour faire tourner le projet, et une explication pour les installer. Fournissez un lien vers de bons guides d’installation, s’il en existe.
• Téléchargement du code source
  • Donnez des instructions détaillées sur comment télécharger le code source du projet, dont les obstacles et problèmes fréquemment rencontrés.
  • S’il existe plusieurs versions du projet, dites clairement quelle version ils doivent télécharger.
• Comment voir / tester les changements
  • Expliquer aux contributeurs comment voir et tester les changements qu’ils ont effectués. Ceci peut varier selon ce qu’ils ont changé, mais faites votre possible pour couvrir les changements les plus fréquents. Cela peut être, tout simplement, afficher un document html dans un navigateur, mais ce peut aussi être plus compliqué.

L’installation pourra différer pour chaque contributeur en fonction de leur système d’exploitation. Vous aurez probablement besoin de créer des instructions séparées pour les utilisateurs de Windows, Mac et Linux, dans différentes parties de votre guide. Si vous entendez ne supporter le développement que pour un seul système d’exploitation, assurez-vous que cela soit dit clairement pour les utilisateurs,

Exemple:

Vous pouvez voir comment OpenHatch annonce cela dans son guide d’installation. Les instructions pour tester des changements peuvent être trouvées là. Des tâches plus spécifiques peuvent avoir leur documentation additionnelle (par exemple la documentation concernant les différents changements du code).

Contributions et retours

Comment les contributeurs doivent-ils procéder pour amener leurs modifications au projet ? Est-ce qu’ils soumettent une pull request sur Github ? Doivent-ils générer un patch et l’attacher à un ticket sur le système de tickets ? Assurez-vous que cette information est explicitement fournie.

Example :

Le guide d’OpenHatch pour soumettre des changements peut être trouvé ici.

Il est aussi utile d’indiquer aux gens comment ils peuvent faire des retours/signaler des bugs sur le projet. Si votre projet n’a pas de système de suivi de tickets, envisagez d’en créer un. Sur Github, tous les dépôts disposent du système de tickets (bien que vous ayez à l’activer en allant dans Settings puis Features). Il y a beaucoup d’autres systèmes de suivi de tickets.

Si votre projet est de petite taille, vous pouvez ne pas avoir besoin ou ne pas vouloir de systèmes de suivi de tickets. Aucun problème. Le principal est que les contributeurs sachent comment vous remonter des informations.

Example :

Les problèmes avec le projet « Open Source Comes to Campus » peuvent être signalés ici. La plupart des autres problèmes liés à OpenHatch peuvent être signalés là.

Les outils tels que le suivi de tickets sont très utiles pour communiquer de manière asynchrone. Ce n’est peut-être pas la solution la plus appropriée lors d’un événement physique. Si vous voulez changer les choses pour l’occasion – comme demander aux participants de vous notifier par IRC les liens vers les nouveaux tickets, pour éviter qu’ils ne passent entre les mailles du filet – assurez-vous de leur en parler !

Vérifiez votre documentation

Vérifiez que cette documentation est complète et effective en la testant auprès de personnes qui n’ont pas participé à votre projet auparavant. Pour chaque sytème d’esploitation, trouvez au moins une personne pour lire votre documentation, tenter d’installer, faire et tester des modifications et participer aux différentes modifications du projet (au choix de votre testeur, ces modifications peuvent être des faux changements ou des vraies tâches). Vérifiez que vos testeurs ont des compétences et/ou une expérience similaire à celle des nouveaux arrivants à votre évènement.

Si vous rencontrez des difficultés pour trouver des personnes pour vous aider, essayez la chaine #openhatch sur IRC.

Assurez-vous que tous les problèmes qui surviennent lors de ce processus de vérification soient intégrés à la documentation. Une fois que la documentation a été vérifiée, ajoutez une ligne au début de votre guide pour annoncer ce qui a été vérifié et quand.

Par exemple :

Instructions de l’environnement de développement testées avec succès sur Ubuntu 12.04 (le 03/10/2013), Mac OS X 10.8 (le 01/10/2013) et Windows XP (en janv. 2005). Vous pouvez consulter cette démarche à OpenHatch ici.

Idéalement, vous devriez vérifer que tout fonctionne : installer, faire des modifications, les tester et les intégrer. Si vous n’avez le temps que pour une seule de ces tâches, nous vous recommandons de vérifier l’intallation. Notre expérience nous a appris que c’est sur ce point qu’émergent la plupart des problèmes.

Définir les tâches des participants

Retournons aux objectifs de l’événement dont nous avons parlé dans la première section. Chaque objectif devrait être décomposé en étapes distinctes qui permettront de l’atteindre. Ces étapes sont les tâches à confier aux participants.

Ces tâches devraient inclure un résumé en anglais simple aussi bien que les informations sur la localisation des modifications (par exemple, quels fichiers ou fonctions sont altérés). Nous recommendons d’inclure une liste des compétences nécessaires (par exemple : compétences en design, Python basique) et des outils (par exemple: Développement sur environnement Mac). Il est aussi utile d’inclure le nombre estimé d’heures que la tâche va prendre, d’étiqueter certaines tâches comme plus ou moins importantes, et de marquer où quelle tâche est dépendante d’une autre.

Cela semble représenter beaucoup de travail mais cela devrait aider vos participants à trouver rapidement et facilement les tâches appropriées pour eux. Etant donné que l’un des objectifs principaux d’un événement en personne est de donner une expérience positive aux participants, nous pensons que cela en vaut la peine.

Créer un système pour suivre les tâches

Nous recommandons l’utilisation d’un wiki ou un document de planification similaire pour garder une trace des tâches. OpenHatch dispose d’un navigateur pour suivre les tâches que nous utilisons pour nos événements. Vous pouvez, si vous le souhaitez, faire un fork et l’adapter à votre projet ou événement ; cependant, nous vous recommandons d’attendre un peu, car nous allons bientôt faire de grosses améliorations. Quelque chose de très simple, comme un etherpad (NdT : ou Framapad), peut également faire l’affaire (ici, un cadre et un service exemple que vous pouvez utiliser).

Préparer les tâches

Pour vous rendre compte du nombre de tâches à préparer, nous vous recommandons de vous baser sur la durée de l’événement et le nombre de participants attendus pour prédire la charge en temps/homme de votre projet. Vous pouvez utiliser les estimations de temps que vous avez faites pour évaluer chaque tâche. Nous suggérons que vous prévoyiez 30% de plus que ce dont vous pensez que vous aurez besoin : il vaut mieux avoir trop que pas assez.

Exemple :

• Objectif de base : parcourir l’interface et étiqueter les tickets selon le type de résolution nécessaire. Est-ce qu’un bug doit être vérifié ? Est-ce qu’un patch doit être testé ? Une fonctionnalité doit-elle être rattachée à un jalon ?
  • Tâche 1 : étiqueter les problèmes
    • Compétences et outils nécessaires : compétences de base en anglais, connaissance des concepts de vérification, tests, jalons…
    • Temps estimé : ~20 minutes par problème
    • Pour démarrer : prenez connaissance du suiveur de tickets, et comment il affiche les informations. (Voyez cette documentation.) Demandez un accès Administrateur pour pouvoir ajouter des étiquettes au suiveur.
    • Pour chaque problème : lisez la discussion relative à chaque problème, et identifiez où la communauté intervient dans le signalement de ce problème. Si c’est un bug non vérifié, ajoutez le label non vérifié. Si c’est un patch non testé, ajoutez l’étiquette patch non testé, etc. Si c’est une fonctionnalité qui n’est rattaché à aucun jalon, ajoutez l’étiquette jalon nécessaire.
• Objectif étendu : utilisez les étiquettes comme un guide pour résoudre chaque ticket. Vérifiez les bugs, testez les patch, etc.
  • Tâche 1 : Vérifier les bugs
    • Compétences et outils nécessaires : compétences de base en anglais, et dans l’idéal connaître les machines virtuelles pour effectuer des tests sur plusieurs OS.
    • Temps estimé : 20 minutes par bug (variance élevée).
    • Pour démarrer : téléchargez l’environnement de développement et assurez vous que vous pouvez lancer le projet. Assurez vous que vous avez un compte sur Le suiveur de tickets et que vous savez ajouter des commentaires ou changer les étiquettes.
    • Pour chaque bug : essayez de reproduire le bug. Enregistrez les résultats dans un commentaire, avec des informations concernant le type de l’OS et sa version. Si possible, effectuez le test sur plusieurs navigateurs. S’il y a plusieurs commentaires récents sur les trois OS majoritaires, ajoutez l’étiquette prêt pour test par le mainteneur (NdT : ready_for_maintainer_review).

Quoi qu’il en soit, les participants doivent être rattachés à une tâche correspondant à leurs compétences et à leurs intérêts. Effectuer ce travail préparatoire fera démarrer les participants immédiatement plutôt que de les faire attendre que vous leur suggériez une tâche adéquate. Dans l’idéal, les organisateurs d’événements auront collecté des informations sur les compétences et intérêts des participants bien en amont, donc vous pourrez adapter la liste à votre groupe de contributeurs.

Rendre explicites les étapes de chaque tâche facilite l’entraide entre les participants. En identifiant clairement les compétences et concepts nécessaires, il devient plus facile pour les gens de dire : « Oh, je comprends comment faire ça ! Attends, je vais te montrer ».

Suite

Il est possible que les contributeurs ne puissent pas finir les tâches sur lesquelles ils travaillent pendant l’événement, ou qu’ils veuillent continuer à participer au projet en travaillant sur d’autres tâches. Penser en amont de l’événement à comment vous allez organiser sa suite rend plus facile l’échange d’informations avec les participants et la planification de la direction de votre projet.

Nous recommandons de demander à chaque participant de répondre aux questions suivantes à propos des tâches sur lesquelles ils ont travaillé. Donnez leur cette liste au début de l’événement : cela les aidera à documenter ce qu’ils font. Vous pouvez imprimer cette liste, l’envoyer par mail aux participants, faire un formulaire web, comme vous préférez.

Par exemple :

• Pour chaque tâche sur laquelle vous avez travaillé, veuillez répondre aux questions suivantes :
  • Sur quelle tâche avez-vous travaillé ?
  • Veuillez documenter brièvement votre workflow. Quelles étapes, dans quel ordre, pourquoi ?
  • Où puis-je trouver le travail que vous avez réalisé pendant l’événement ? Ceci inclut le code, la documentation, les maquettes, et autres choses.
  • Si vous avez créé des comptes pour le projet, veuillez lister les sites et les noms des comptes. Enregistrez le mot de passe dans votre gestionnaire de mot de passes préféré, ou assurez vous que moi ou un autre mainteneur y aie accès.
  • Quels obstacles avez-vous rencontré en travaillant sur cette tâche ? Avez-vous des retours à me faire pour améliorer le processus pour les futurs contributeurs ?
  • Voudriez-vous rester impliqué dans ce projet ? Si oui, dans quelle mesure ?

S’il y a suffisamment d’enthousiasme pour continuer le travail, assurez-vous de rester en contact ! Nous suggérons que vous rassembliez les emails des participants intéressés et que vous les contactiez dans les 48 heures suivant l’événement. Dans votre email, remerciez-les pour leur aide et fournissez des informations sur comment rester dans la communauté par, par exemple, IRC ou des listes de diffusion.

Nous recommendons aussi de prévoir un rendez-vous suite à l’événement. Si vous êtes tous originaires de la même région, essayez de fixer une date après l’événement pour vous et votre équipe au café du coin, à l’espace de coworking, ou à une soirée-projet. Si vous êtes éloignés géographiquement, fixez une date pour vous rencontrer sur IRC ou sur Google Hangout. 2-3 semaines après l’événement est un bon créneau, toutefois cela dépend si vous et vous nouveaux contributeurs êtes très occupés.

Checklists

Merci de votre attention ! Pour vous aider à garder un oeil sur chaque étape, nous avons créé deux checklists pour vous. La version détaillée inclut tous les conseils ci-dessus. La checklist la plus courte inclut les conseils que nous pensons les plus importants. Nous vous recommandons de démarrer avec la cheklist la plus courte. Une fois que vous avez accompli correctement cette checklist, vous pouvez revenir et faire les étapes supplémentaires si vous avez le temps et l’énergie.

Pour voir et/ou imprimer les checklists, se rendre ici.

Remerciements

Merci à tous ceux qui ont contribué ou aidé au projet.

Contributeurs

• Shauna Gordon-McKeon : maintenance, contenu
• Ni Mu : design
• Sheila Miguez : testeuse
• Asheesh Laroia : testeuse

Pour aller plus loin

• Open Advice (NdT : entièrement traduit par nos soins)
• Producing Open Source Software (NdT : entièrement traduit par nos soins)

La France a fait le choix depuis de nombreuses années de considérer l’informatique à l’école et jusqu’au collège, uniquement à travers ses usages via le B2I. L’Éducation nationale perçoit le numérique comme un outil utile aux autres apprentissages.

Cette vision n’est pas forcément mauvaise mais elle semble trop restrictive. Le numérique ne peut se limiter à son seul usage au service des autres disciplines. Il pourrait être pertinent de mettre en place un réel enseignement de l’informatique comme il en existe dans d’autres pays ou même en France (mais seulement en option au lycée).

Les programmes de l’école primaire étant en pleine ré-écriture actuellement, Serge Abiteboul, Jean-Pierre Archambault, Gérard Berry, Colin de la Higuera, Gilles Dowek et Maurice Nivat ont envoyé au Conseil supérieur des programmes ce texte, que nous reproduisons ci-dessous, présentant les grandes orientations de ce que pourrait être un programme d’informatique à l’école primaire.

Proposition d’orientations générales pour un programme d’informatique à l’école primaire

URL d’origine du document (EPI)

Ce texte propose des orientations générales permettant de structurer un futur programme d’informatique à l’école primaire.

Comme dans les autres disciplines fondamentales, la sensibilisation précoce aux grands concepts de la science et technique informatique est essentielle. Elle donne des clés aux élèves pour comprendre le monde qui les entoure, elle évite que se forgent des idées fausses et représentations inadéquates, elle fabrique un socle sur lequel les connaissances futures pourront se construire au Collège et au Lycée. À l’École, il est important de montrer les liens qui unissent les concepts de l’informatique et ceux enseignés dans les autres disciplines, ainsi que ceux qui les unissent aux objets familiers que les élèves utilisent tous les jours. Sur ces deux points, nous pouvons nous appuyer sur des expériences longues et riches d’enseignements menées en France et hors de France.

Ces orientations s’inscrivent aussi dans une vision plus globale : après cette première sensibilisation à l’École primaire, vient le temps, au Collège, de l’acquisition de l’autonomie puis, au Lycée, celui de la maîtrise des concepts. Il est important de veiller à la progressivité et à la cohérence des programmes pour l’École, le Collège et le Lycée.

La question décisive de la formation des Professeurs n’est pas traitée dans ce document. Disons simplement qu’il nous semble essentiel que les Écoles supérieures du professorat et de l’éducation intègrent une formation, mais surtout une certification, en informatique.

L’école primaire doit être le temps de la découverte des concepts fondamentaux de l’informatique, celui où l’on parle aux élèves, avec leurs mots, à partir de leur quotidien et de leurs connaissances acquises dans les autres disciplines, d’informations, de langages de programmation, d’algorithmes et de machines. L’enseignement de l’informatique à l’École nous semble être trop souvent limité à l’utilisation d’ordinateurs et de logiciels créés par d’autres. Cette vision dénature une discipline scientifique et technique qui donne un rôle essentiel à l’abstraction et à l’expérimentation personnelle. Faire de l’informatique ne consiste pas à passer des heures devant un écran, mais à acquérir des notions fondamentales et universelles. L’initiation à l’informatique doit donc n’être liée ni à un ordinateur particulier, ni à un logiciel particulier, ni à un langage particulier. Elle doit par ailleurs chercher un équilibre entre des activités fondées sur l’utilisation d’un ordinateur et des activités « débranchées », c’est-à-dire ne recourant pas à une telle utilisation.

Des logiciels aux concepts

Les activités s’effectuant avec un ordinateur débutent avec l’apprentissage des logiciels les plus courants : logiciel de courrier électronique, navigateur, moteur de recherche, logiciel de traitement de texte, tableur, etc. Cet apprentissage ne doit pas rester une fin en soi, mais aussi conduire à s’interroger sur le fonctionnement de ces objets, menant ainsi à découvrir certains concepts de l’informatique.

Beaucoup d’élèves, par exemple, savent envoyer un courrier électronique, mais ils ne cherchent pas toujours à savoir comment un tel message arrive dans la boîte aux lettres de son destinataire. Pourtant l’apprentissage de l’utilisation d’un logiciel de courrier électronique est une occasion de les amener à se poser cette question et à y chercher des réponses. Cette interrogation, cette énigme, peut être l’occasion d’une recherche collective, chaque élève proposant une hypothèse et critiquant celles des autres. Elle peut donner lieu à une contextualisation historique : l’acheminement d’un courrier électronique n’est peut-être pas si différente de l’acheminement d’un courrier postal, qui fonctionnait déjà dans l’Antiquité quand les ordres militaires irriguaient de vastes empires. Cette question permet donc d’introduire la notion de réseau – les ordinateurs sont reliés entre eux par des câbles ou par voie aérienne – et de routage – un message doit trouver son chemin dans le labyrinthe que constituent ces milliards d’ordinateurs reliés entre eux.

Le Web et ses logiciels — navigateurs, moteurs de recherche, etc. — permet de poursuivre la réflexion sur ces questions, mais aussi d’en poser de nouvelles. L’acheminement du contenu d’une page d’un serveur Web jusqu’à l’ordinateur de l’école suit les mêmes principes que l’acheminement d’un courrier électronique. À un certain niveau d’abstraction rien ne distingue un courrier du contenu d’une page web, et les méthodes permettant d’acheminer l’un permettent également d’acheminer l’autre. Mais de nouvelles questions apparaissent : quelle est l’origine des informations auxquelles on accède ? Qui écrit ? Où les informations sont-elles enregistrées ? Comment sont-elles identifiées ? Les élèves peuvent même concevoir leur propre page web et devenir ainsi des participants actifs du Web ; c’est le meilleur moyen de comprendre que n’importe qui peut dire n’importe quoi dans une page web, et de s’interroger sur la pertinence de l’information que l’on y trouve. Le Web est aussi l’occasion d’aborder la question de la recherche des pages contenant certains mots-clés, fondée sur la notion d’indexation : les moteurs de recherche recherchent d’abord les documents qui contiennent des occurrences des mots signifiants de la question qu’on leur pose. L’indexation conduit à une réflexion sur le sens d’un texte, puisqu’elle vise à identifier ce dont le texte parle, même si cette réflexion est souvent réduite à l’identification de mots clés. Or, la compréhension et l’extraction du sens d’un texte sont parmi les buts fondamentaux de l’enseignement de la langue ; il faut désormais y adjoindre une initiation à l’indexation et une réflexion critique sur la pertinence d’un texte vis-à-vis d’une question posée.

L’initiation à l’informatique doit aussi passer par la découverte des concepts fondamentaux de langage, d’information, d’algorithme et de machine, sans toujours utiliser un ordinateur pour cela.

Des langages simples

Un langage formel se distingue d’une langue naturelle par sa spécialisation, son caractère artificiel, le caractère limité de son lexique et la simplicité des règles qui régissent sa grammaire. Un exemple simple est le langage formé de quatre mots : « nord », « sud », « est » et « ouest » et d’une construction, la séquence, qui permet de former des suites de tels mots. Ce langage permet d’indiquer un chemin à suivre sur une grille carrée, par exemple sur le carrelage du préau d’une école. L’expression « nord, nord, nord, est, est, est, sud, sud, sud, ouest, ouest, ouest » indique ainsi à un élève de se déplacer de trois carreaux vers le nord, puis de trois carreaux vers l’est, puis de trois carreaux vers le sud et enfin de trois carreaux vers l’ouest, parcourant ainsi un carré sur le sol.

Ce même mouvement peut être exprimé dans un autre langage qui ne comprend que trois mots : « avancer », « tourner à droite » et « tourner à gauche », composés par l’opération de séquence : « avancer, avancer, avancer, tourner à droite, avancer, avancer, avancer, tourner à droite, avancer, avancer, avancer, tourner à droite, avancer, avancer, avancer, tourner à droite ».

L’apprentissage de ces deux langages permet de mettre en place de nombreuses activités et de poser de nombreux problèmes. Une première activité consiste à interpréter les instructions données par un autre élève ou à trouver la phrase qui commande d’aller d’un point du préau à un autre. C’est le jeu du « robot idiot ». Ce problème est le même que celui de la conception d’un programme dans un langage tel que Logo (il y a de nombreux enseignements à tirer de l’utilisation de Logo à l’École primaire), mais où un élève joue le rôle de l’avatar informatique afin de mieux s’approprier le lien qui s’établit entre une expression du langage et une action. On peut ensuite passer à des exercices plus élaborés, comme la traduction d’une expression d’un langage dans un autre – par exemple une expression formée dans le premier des langages présentés ci avant dans le second –, la mise en évidence de la redondance d’un langage – par exemple, un « tourner à gauche » pourrait être remplacé par une séquence de trois « tourner à droite ». Il est aussi possible d’évoquer dans une telle activité la notion de bug : une petite erreur dans une instruction exprimée dans le second langage, par exemple un « tourner à droite » de trop, change complètement la trajectoire et envoie l’élève n’importe où.

Ce type d’activité permet aussi d’aider les élèves à comprendre, dans un cadre très simplifié, quelques-uns des traits essentiels de la langue écrite : son caractère conventionnel, la nécessité de règles et la correspondance entre les mots et les actions. Elle leur permet aussi de comprendre qu’il est possible de calculer, non avec des nombres, mais avec des mots.

Des langages moins simples

Ces activités débranchées peuvent mener à des activités sur machine, par exemple à des activités de programmation dans un langage tel que Scratch, développé au Massachusets Institute of Technology spécialement pour enseigner la programmation à l’École. Il permet d’assembler visuellement des instructions et de créer des tests et des boucles, afin d’animer de petits personnages. Ce langage est emblématique de cette démarche ludique où les élèves créent des objets informatiques, d’abord par un simple dessin, puis les animent et augmentent leurs savoir-faire au fur et à mesure de leur découverte personnelle des possibilités offertes. De telles activités de programmation – ou de codage – sont aujourd’hui fréquemment proposées aux élèves hors de l’École. Les mettre en œuvre pour tous les élèves permettra à toutes et tous de profiter de ce type d’apprentissages essentiel dans le monde dans lequel nous vivons.

D’autres activités autour de la notion de langage sont liées à la programmation de robots physiques animés par des algorithmes. Les clubs de robotique développent ce type d’activités et leur efficacité auprès des enfants est un fait avéré.

Des activités plus difficiles peuvent être proposées à la fin de l’école primaire : des exercices visant au rangement, à la classification de données, à l’analyse de multiples situations combinatoires simples, à la recherche d’objets ayant certaines propriétés dans un ensemble fini d’objets. Les expériences menées hors de France et en France, à l’École et hors de l’École, montrent qu’il est possible d’aller assez loin dans cette direction, même avec de jeunes enfants.

La notion d’information

La notion d’information est aussi une formidable clé pour entrer dans l’informatique. La première notion à transmettre est celle de représentation : toute information peut être représentée par une suite de lettres dans un alphabet fini, par exemple par une suite de 0 et de 1. Les images, les sons, les textes, les nombres ont tous une représentation en machine, qui permet de les mémoriser, de les transmettre, de les transformer et de les reproduire à l’infini. Il est possible dès l’école primaire d’introduire l’atome d’information, le bit, et de se demander combien de bits sont nécessaires pour représenter une information. Pour exprimer si la lumière est allumée ou éteinte, un bit suffit, alors que pour décrire la couleur des cheveux d’une personne – bruns, châtains, blonds ou roux – deux bits sont nécessaires. Pour décrire une couleur parmi les 16 777 216 du système RVB, vingt-quatre bits suffisent. Ici apparaît la notion de quantité d’information contenue dans un message, qui est, en première approximation, sa taille.

Ces notions peuvent être introduites par des jeux. On peut, par exemple, proposer un langage pour coder un petit dessin en noir et blanc : il faut pour cela décomposer le dessin en pixels, puis coder chaque pixel, qui est ou bien noir ou bien blanc, par un bit. Par exemple, en supposant que 1 code pour un pixel noir et 0 pour un pixel blanc, la suite de vingt bits 11111000111100011111 représente un dessin bi-dimensionnel :

1 1 1 1
1 0 0 0
1 1 1 1
0 0 0 1
1 1 1 1

ou encore

Deux élèves ou groupes d’élèves, de part et d’autre d’un paravent, peuvent ainsi s’échanger, par oral, des dessins sur une grille de vingt-cinq ou cent pixels. Il est cependant probable que des erreurs apparaissent lors de la transmission, ce qui sera l’occasion de s’interroger sur la manière de corriger ces erreurs, par exemple en introduisant une forme de redondance dans le message. Il est aussi possible d’envoyer les bits à l’envers, du dernier au premier, et de s’interroger sur l’effet de cette transformation sur le dessin.

La notion d’algorithme

Un algorithme est une manière de résoudre un problème en effectuant des opérations élémentaires mécaniquement et donc sans réfléchir. Tout algorithme doit s’exprimer d’une part dans une langue naturelle, ce qui est nécessaire pour sa compréhension, et d’autre part dans un langage technique précis, ce qui est indispensable pour faire en sorte que la machine puisse l’effectuer automatiquement. Les algorithmes qui transforment des symboles écrits – addition, soustraction, déclinaisons, conjugaisons, etc. – sont aussi anciens que l’écriture. Mais l’humanité a bien entendu utilisé des algorithmes avant même la naissance de l’écriture, pour tisser des étoffes, tailler des silex, etc.

Comme les notions de langage et d’information, la notion d’algorithme peut s’aborder par des activités « débranchées ». L’initiation peut commencer par l’identification d’algorithmes simples que les élèves utilisent tous les jours : pour s’habiller il faut mettre son tee-shirt avant son pull ; pour faire une tarte aux pommes, il faut mettre les pommes avant la cuisson de la pâte, mais pour une tarte aux fraises, il faut mettre les fraises après la cuisson.

Une deuxième étape est une interrogation sur les constructions qui permettent d’exprimer un algorithme :

• la séquence : faire ceci puis cela ;
• le test : si telle condition est vérifiée, alors faire ceci, sinon faire cela ;
• la boucle : faire ceci trois fois, ou alors répétitivement jusqu’à ce que telle condition soit vérifiée.

La notion d’algorithme est une formidable opportunité de relier l’informatique aux autres disciplines enseignées à l’École telles le français, les mathématiques ou les travaux manuels, car beaucoup des connaissances enseignées dans ces disciplines se formulent sous la forme d’algorithmes. Par exemple, l’algorithme de l’addition de deux nombres de trois chiffres décimaux peut être décomposé en une boucle à l’intérieur de laquelle se trouvent des instructions élémentaires en séquence : la lecture d’un chiffre de chacun des nombres et de la retenue, la consultation d’une table qui permet d’ajouter trois chiffres, l’écriture d’un chiffre du résultat et celle de la retenue. De nombreux exercices de mathématiques proposés en cycle 2 nécessitent la mise en œuvre d’un algorithme, souvent formé d’une unique boucle, mais où les notions de donnée, d’instruction, de test, de terminaison apparaissent clairement.

Avant même l’apprentissage de l’algorithme de l’addition, l’apprentissage de l’art de compter des objets recèle une possibilité de poser plusieurs questions d’informatique. Quoi que l’on compte, il faut commencer par choisir arbitrairement un élément auquel on attribue le nombre 1, puis choisir un deuxième élément, distinct du premier, lui attribuer le nombre 2, etc. Des questions essentielles apparaissent : comment se saisir d’un élément, lui attribuer un nombre et le marquer afin de ne pas le compter deux fois, tout en n’oubliant aucun élément dans l’énumération. Cette question du marquage est résolue de façons différentes selon les objets comptés : s’il s’agit des billes contenues dans un sac, on se munit d’un deuxième sac dans lequel on transfère une à une les billes déjà comptées. Si on compte des croix dessinées sur un cahier, on les entoure d’un cercle. Mais quel algorithme utilise-t-on pour compter les tuiles sur un toit ? Ou les arbres dans une forêt ?

De même l’accord d’un participe passé peut se décomposer en deux tests imbriqués, l’un sur le verbe auxiliaire utilisé, l’autre sur la présence d’un complément d’objet situé avant le verbe. Ces algorithmes s’apprennent en mathématiques, en français, etc., par imitation d’exemples de difficulté graduelle. En informatique, il est possible de porter un nouveau regard plus systématique sur certains de ces algorithmes et de montrer comment ils se construisent à partir des constructions de séquence, test et boucle. Il est aussi possible de commencer à sensibiliser les élèves au fait que ce sont les mêmes constructions qui permettent de construire les algorithmes appris en français, en mathématiques ou en travaux manuels, anticipant ainsi la notion d’universalité, qui sera développée dans la suite du cursus des élèves.

La notion de machine

La notion de machine peut paradoxalement, elle aussi, être abordée par des activités débranchées. Il est par exemple possible de montrer aux élèves combien il est difficile pour eux de se comporter comme des robots, et de les amener à s’interroger sur l’origine de cette difficulté.

Le jeu du « robot idiot » peut être réutilisé ici, non pour réfléchir à la notion de langage, mais à celle d’architecture des machines. On peut fabriquer de petites cartes avec les mots « avancer », « tourner à gauche », « tourner à droite » et donner au robot humain un paquet de cartes qui est son « programme ». L’élève n’a désormais plus le droit d’écouter ce que lui disent ses camarades, mais doit uniquement lire une carte, exécuter une action et passer à la carte suivante. Pour d’autres programmes, tels le programme de l’addition, on pourra lui adjoindre des boites en carton – des variables – dans lesquelles il pourra stocker une valeur. Il illustrera alors le fonctionnement d’un processeur qui lit une instruction, exécute une action et passe à l’instruction suivante.

Il est aussi utile d’attirer l’attention des élèves sur quelques éléments clés de l’histoire des machines. On pourra leur raconter comment les Péruviens calculaient avec des ficelles couvertes de nœuds – les kipu –, et comment un boulier sert de béquille à notre mémoire : on y « pose » les chiffres des nombres à additionner en déplaçant les boules, tandis que l’accumulation des boules permet d’additionner. On peut montrer la conception au XIXe siècle, de machines munies d’un moteur qui ne nécessitaient pas d’intervention humaine pour effectuer un calcul. Enfin au XXe siècle, illustrer la révolution conceptuelle des premiers ordinateurs, machines capables d’exécuter non plus un calcul particulier mais n’importe quel calcul, ce qui demande un langage pour les programmer.

Évoquer les machines du passé, du boulier au minitel, permet de s’interroger sur ce qui est invariant dans l’histoire des machines à traiter de l’information comme les concepts de représentation, d’algorithme, de langage, la généralité de l’ordinateur, etc. et, au contraire, de ce qui évolue constamment : la vitesse de calcul et la capacité des machines, leur taille, leurs domaines d’application, leur liaison avec le monde physique etc. Cela permet aussi de développer un sens de l’histoire : comment vivions-nous, comment communiquions-nous, comme cherchions-nous de l’information avant l’informatique ?

Un enseignement adapté à l’élève et à son rapport au monde

Ce qui est ébauché dans ce document répond à des objectifs spécifiques aux élèves de l’École primaire. Nous avons cherché à proposer des activités ludiques mais instructives au sens profond du terme, et adaptées aux connaissances et aux capacités des élèves. Mais l’essentiel n’est pas là. Il est d’abord dans le fait que l’informatique est une science et une technique faite d’abstractions, et que ces abstractions ne sont pas accessibles aux élèves directement. Elles doivent être appréhendées à travers des situations concrètes et de l’expérimentation personnelle. C’est le levier des activités débranchées, qui propose aux enfants de manipuler des concepts à travers des gestes de leur propre corps et la manipulation d’objets familiers. Ensuite, à partir de sept ans, les enfants entrent dans l’âge des « pourquoi », mais à un niveau métaphorique. On doit donc leur proposer des explications, certes provisoires, des concepts informatiques, mais en mettant en place un vocabulaire précis qui leur permettra en grandissant d’affiner et d’enrichir les concepts associés aux mots.

Les activités débranchées sont complémentaires des activités avec un ordinateur, notamment l’apprentissage des logiciels les plus courants et l’utilisation des logiciels pédagogiques disponibles sur les ordinateurs et les tablettes, par exemple ceux d’apprentissage de la lecture, qui conduisent aussi à se poser des questions d’algorithmique humaine et mécanique.

On dira « langage », « information », « algorithme », « machine » et les enfants grandiront en se souvenant que l’information est aussi une quantité qui se mesure, qu’un langage peut être une forme de codage très rudimentaire, qu’une méthode devient un algorithme quand on a éliminé tous les implicites de la langue ordinaire et qu’une machine n’est qu’un outil qui permet d’exécuter des algorithmes.

Le 6 décembre 2013

Serge Abiteboul, Professeur au Collège de France (2012), membre de l’Académie des sciences, membre du Conseil National du Numérique.

Jean-Pierre Archambault, Président de l’association Enseignement Public et Informatique (EPI).

Gérard Berry, Professeur au Collège de France, membre de l’Académie des sciences et de l’Académie des technologies.

Colin de la Higuera, Président de la Société Informatique de France (SIF).

Gilles Dowek, Directeur de recherche à l’INRIA, Grand Prix de philosophie de l’Académie Française.

Maurice Nivat, membre de l’Académie des sciences.

Ce document a été envoyé au Conseil Supérieur des Programmes (CSP), le samedi 7 décembre 2013.

Crédit photo : Lupuca (Creative Commons By-Sa)

Lorsque l’on effectue une recherche dans l’interface utilisateur Unity de la distribution GNU/Linux d’Ubuntu, on nous sort des résultats internes au disque dur de notre ordinateur mais aussi par exemple des références du site Amazon, ce qui avait fait couler beaucoup d’encre à l’époque.

Et si demain nous pouvions également avoir des fichiers torrents qui, comme chacun le sait ou devrait le savoir, n’abrite pas que des films illégalement partagés mais aussi plein de ressources sous licences libres ?

Ubuntu va ajouter la recherche de torrents pour inclure la culture libre dans l’expérience utilisateur

Ubuntu Will Add Torrent Search to Embed Free Culture Into User Experience

Andy – 4 janvier 2014 – TorrentFreak
(Traduction : Garbust, Fchaix, Asta, Monsieur Tino, RyDroid + anonymes)

Il est prévu d’inclure par défaut dans Ubuntu une nouvelle fonctionnalité qui autorisera les utilisateurs (de The Pirate Bay) à faire leurs recherches BitTorrent directement depuis le bureau Unity. Le créateur de l’outil a informé TorrentFreak que bien que des efforts restent à faire, le but de l’outil — qui est soutenu par Mark Shuttleworth, le fondateur de Canonical — est d’apporter la culture libre directement dans l’expérience utilisateur d’Ubuntu.

Au début de décembre a été faite une annonce agréable pour les utilisateurs d’Ubuntu. Le développeur David Callé a révélé qu’un nouveau scope (plugin de recherche) pour torrents était maintenant disponible pour les distributions basées sur Debian GNU/Linux.

Dans un premier temps, Callé était sceptique sur le fait que le scope soit inclus dans Ubuntu par défaut car il retournera inévitablement du contenu illégal. Il a entre autre peur que cela « génère beaucoup de FUD pour Ubuntu ». Cependant, Mark Shuttleworth, le fondateur de Canonical, a vite dissipé les craintes de Callé.

« L’outil est très utile et il est parfaitement justifié de le rendre disponible par défaut. Nous utilisons les torrents pour distribuer Ubuntu. Alors s’il vous plaît, ne vous retenez pas !? » a écrit Shuttleworth.

Nous avons rencontré David Callé pour en savoir plus sur son expérience des torrents et ce qui l’a motivé à créer l’outil.

« J’utilise les torrents pour seeder les images ISO de distributions Linux, Ubuntu bien sûr, mais aussi Linux Mint et Fedora. »

« La principale motivation derrière le scope pour torrents était d’apporter la culture libre dans l’expérience utilisateur en la proposant dans la barre de recherche de l’OS. Dans cet esprit, je pousse aussi pour que le scope Jamendo (un service avec des musiques sous Creative Commons) devienne une des sources de musique par défaut. »

David avait clairement présent à l’esprit dans ses hésitations la question de l’image d’Ubuntu. Quels écueils avait-il prévu à ce stade précoce et a-t-il changé d’avis ?

« J’ai encore des réserves : le prototype actuel utilise la base de The Pirate Bay en arrière plan et n’en est qu’à ses débuts en matière de filtrage », explique le développeur.

« Étant donné qu’Ubuntu est utilisé dans de nombreuses écoles et administrations publiques, ma condition pour le rendre disponible par défaut est d’avoir un filtrage de licence, pour promouvoir les travaux sous licence libre et les contenus du domaine public. Les principales conditions d’un projet libre sont le temps et l’intérêt ; en voyant des gens (en particulier le fondateur d’Ubuntu) m’apporter leur aide et leur soutien, je suis devenu plus confiant quant à la réussite de cet objectif. »

Alors que le mot « filtrage » est susceptible de causer quelques troubles, David indique que tous les filtrages peuvent être retirés pour que les utilisateurs puissent, s’ils le souhaitent, bénéficier de la recherche complète proposée par BitTorrent.

« Cela peut paraître un cliché, mais le partage et la liberté sont au cœur de Linux et je ne pense pas que quelqu’un s’investisse dans Linux sans se soucier du protocole BitTorrent », explique-t-il. « Son efficacité est également la raison pour laquelle toutes les distributions Linux utilisent les torrents pour distribuer leurs images. »

Alors que le scope des torrents veut tenter un filtrage dans le but de promouvoir les licences libres et le contenu du domaine public, les FAI des utilisateurs de certains pays tentent eux de se débarrasser totalement de sites comme The Pirate Bay. Y aura-t-il des tentatives pour s’opposer à ce problème ?

« Le dash (NdT : Le tableau de bord) est une partie importante du bureau Ubuntu et c’est même l’écran d’accueil dans la version pour smartphone/tablette. C’est un meta-moteur de recherche qui agrège de nombreuses sources (à peu près 70, telles que DeviantART, SoundCloud, Amazon, etc.) et le scope pour torrents est prévu pour être l’une d’entre elles » explique David.

« Le prototype actuel privilégie les résultats de The Pirate Bay par rapport aux autres sites, il a été vraiment très simple d’y implémenter un filtre pour les contenus adultes. Cela dit, cela va peut être changer et le projet veut utiliser n’importe quel service BitTorrent qu’il peut exploiter pour donner accès à la culture libre. Il sera disponible partout où ils sont ne sont pas bloqués. »

Le temps dira à quel point le scope est pertinent par rapport aux résultats qu’il retourne (le filtrage n’est pas encore au point d’après David), mais pour ceux qui cherchent à utiliser et promouvoir la culture libre c’est probablement quelque chose à suivre.

« Oui, nous venons de rendre open source la dernière année de notre vie : tout le code, le graphisme, et la musique de CodeCombat ! » Ainsi s’exprime NIck sur le blog de ce jeu particulier puisqu’on y fait l’apprentissage sérieux mais ludique du JavaScript.

Une libération exemplaire dans la mesure où, comme cela arrive trop souvent, ça n’est pas qu’un effet d’annonce. Tout a en effet été minutieusement préparé sur GitHub pour faciliter la tâche des futurs contributeurs.

Longue vie à CodeCombat…

Nous avons tout mis en open source

We’ve Open-Sourced Everything

Nick – 6 janvier 2014 – CodeCombat Blog
(Traduction : Monsieur Tino, Théotix, goofy, audionuma, baba, Sphinx, Asta, moedium, vvision + anonymes)

CodeCombat est un jeu de programmation pour apprendre à coder ; un concours de codage multijoueurs dans une arène pour affûter vos compétences ; une startup lancée avec un financement par Y-combinator ; et depuis le week-end dernier, le plus important projet open source utilisant Coffeescript et une porte d’entrée géniale pour l’open source et le développement de jeux. Que vous soyez un programmeur novice désireux de vous faire une idée de ce qu’est ce Github ou un gourou de l’open source qui cherche dans quoi mordre à belles dents, regardez notre Github et rejoignez plus de deux cents Grands Mages de CodeCombat dans la construction du meilleur jeu de programmation qui soit.

Oui, nous venons de rendre open source, sous les licences MIT et Creative Commons CC By-SA, la dernière année de notre vie : tout le code, le graphisme, et la musique de CodeCombat !

« Attendez un peu, vous êtes une startup à but lucratif, et vous venez de libérer tout votre code ? Mais vous êtes fou ? »

Nan ! Fermer son code source est peut être le choix fait par pratiquement toutes les startups et studios de jeux vidéo, mais nous pensons que c’est une convention qui doit être repensée. CodeCombat est déjà un projet communautaire, avec des centaines de joueurs se portant volontaires pour créer des niveaux, écrire de la documentation, aider les débutants, faire des tests et même traduire le jeu en dix-sept langues ! Maintenant les programmeurs peuvent se joindre à la fête eux aussi.

Notre noble mission est de vous apprendre à coder. Nous avons plus de 9000 niveaux de difficulté qui vous feront gravir tous les échelons, de simple novice à sorcier du code comme Fabrice Bellard, alors pourquoi ne pas vous lancer dans un projet open source accessible aux débutants pour continuer à apprendre ? Nous ne nous contentons pas de balancer du code en vrac — nous avons travaillé dur pour qu’il soit simple de contribuer. Vous n’avez pas besoin de connaître git, vous n’avez pas besoin d’avoir quoi que ce soit d’installé, et vous n’avez même pas besoin de savoir coder pour aider à résoudre certains problèmes sur notre Github.

Ou alors, si vous êtes intéressés par les compilateurs, les langages de programmation, les simulations physiques, la géométrie, le design, l’expérience utilisateur, l’intelligence artificielle, l’optimisation des performances, le traitement audio, les jeux de stratégie en temps réel, les jeux de rôle, l’internationalisation et la localisation, la sécurité, le dessin vectoriel 2.5D, le développement piloté par les tests, les bases de données, les discussions en visioconférence, les environnements de développement intégrés, ou les débogueurs, vous adorerez hacker ce projet. Avec des technologies sympas, des problèmes détaillés, une documentation complète pour les développeurs, un script convivial pour mettre en place l’environnement de développement et l’équipe de CodeCombat prête à vous aider à mettre en place vos idées, c’est le jeu open source parfait pour débuter. Ne soyez pas timide !

Nous avons besoin de votre aide. Il y a tout juste deux mois, nous avons lancé notre bêta. Il y a deux semaines, nous avons écrit un billet sur les 180 000 enfants qui avaient joué avec CodeCombat cette semaine-là. Il y a une semaine, nous avons essayé un niveau difficile, un défi pour développeur, et presque 10 000 programmeurs chevronnés y ont joué — nous n’avons pas encore fini de répondre à tous ceux qui ont battu notre propre algorithme à plate couture et voulaient qu’on les aide à trouver un boulot de programmeur. CodeCombat devient un phénomène qui dépasse largement le domaine d’un simple jeu. Si vous souhaitez écrire du code qui montrera à des millions de joueurs à quel point ça peut être sympa de programmer, alors cliquez sur ce lien et devenez un Grand Mage. Nous avons vraiment hâte de voir ce que vous avez réalisé.

Vous voulez aider d’une autre façon ? Rejoignez nous en tant qu’Artisan créateur de niveaux, Aventurier bêta-testeur, Scribe de documentation, Diplomate traducteur, Ambassadeur serviable ou Conseiller expert.

Avant Snowden, nous criions dans le désert.

Il en va tout autrement aujourd’hui. Et les gouvernements réalisent soudainement le danger d’avoir choisi des logiciels propriétaires qu’on ne peut évaluer et auditer faute d’accès au code source.

Il ne va pas être facile pour Microsoft, Apple et consorts de répondre ici aux exigences de transparence des autorités brésiliennes qui se tourneront naturellement vers le logiciel libre.

En attendant le tour de la France…

Le gouvernement brésilien va interdire l’achat des logiciels qui ne permettent pas leur plein contrôle

Governo vai barrar compra de software que impeça auditoria

Natuza Nery et Julia Borba – 5 novembre 2013 – Folha de S. Paolo
(Traduction : Ulan, Pierre, JonathanMM)

A partir de l’année prochaine, le gouvernement (brésilien) n’achètera plus d’ordinateurs ou de logiciels qui ne peuvent être pleinement audités par les pouvoirs publics. La directive a été publiée le 5 novembre dernier dans le journal officiel « Diario official da Uniao ».

Ainsi, les systèmes d’exploitation comme Windows (Microsoft) et MacOS (Apple) ne seront plus utilisés si les entreprises concernées font obstacle aux enquêtes sur l’espionnage informatique.

Actuellement, à l’installation d’un logiciel (propriétaire), les utilisateurs acceptent les termes d’utilisation de l’éditeur autorisant éventuellement celui-ci à accéder à leur ordinateur.

Le gouvernement brésilien souhaite avoir le droit de surveiller qui surveille ses concitoyens, et ce dans le but de pouvoir identifier et tracer les tentatives d’espionnage.

Selon le journal « Folha de São Paulo », l’intention n’est pas de promouvoir une conversion massive des parcs informatiques, mais prévenir que les produits actuels ne sont plus conformes aux nouvelles exigences.

De cette manière, il y aura un substitution graduelle des programmes traditionnels (propriétaires) pour des logiciels libres, comme Linux, si nous ne parvenons pas à négocier avec les grandes entreprises.

L’importance accordée par le gouvernement à l’espionnage a augmenté depuis qu’ont été publiés les dénonciations sur l’accès par les services américains aux archives des autorités et entreprises brésiliennes.

Économie

Le gouvernement considère que, en plus d’augmenter la sécurité, la directive entraînera des économies. L’utilisation de logiciels libres met un terme au renouvellement obligatoire des licences de ces programmes.

Interrogé pour la rédaction de cet article, Apple n’a pas souhaité répondre à cette décision.

Microsoft a informé qu’il fournit aux gouvernements « l’accès contrôlé au code source et aux autres informations techniques pour les aider à évaluer la sécurité des produits ». La société a également déclaré qu’elle se met à disposition du gouvernement brésilien pour discuter des détails de la mesure.

Valeur incertaine

Il n’y a pas encore d’estimation de l’impact de cette décision sur les dépenses gouvernementales. Les informations plus précises sur ces coûts ne seront dévoilées qu’après l’application de la directive, quand aura lieu une enquête sur les contrats actuellement en vigueur et les dates d’expirations de ceux-ci. Comme ces licences ont été obtenues à des moments différents, il n’est pas encore possible de faire d’estimation.

Le journal précise que le gouvernement de Dilma Rousseff étudie également avec détermination une autre mesure de sécurité informatique : installer le client de messagerie libre Expresso (Serpro) comme référence sur tout ordinateur public à la place de Outlook, ce qui engendrera des économies supérieures à 60 millions de reais par an (environ 20 millions d’euros).

Crédit photo : Laura Poitras (Creative Commons By)

Les nombreux services de Google sont généralement gratuits mais ils sont aussi propriétaires.

Ainsi les utilisateurs de Gmail s’en sont rendu compte dernièrement : Google modifie quand bon lui semble son interface et ses fonctionnalités. Et nous sommes mis devant le fait accompli de changements qui vont bien plus dans le sens d’une intégration toujours plus poussée avec les autres services Google (Google+ notamment) que d’un réel souci du confort des utilisateurs.

C’est également ce qui est en train de se produire actuellement avec Google Maps qui change d’interface et donc de version de son API, signifiant par là-même que tous ceux qui avaient développé des applications spécifiques avec la version précédente de l’API devront tout recoder avec la nouvelle version.

Une bonne occasion de migrer vers la carte libre OpenStreetMap^[1] à l’aide du site Switch2OSM^[2].

Faut-il mettre à jour la version 2 de l’API de Google ? Libérez-vous plutôt et passez à OpenStreetMap.

Upgrading from Google v2 API? Free yourself and upgrade to OpenStreetMap

5 novembre 2013 – OpenStreetMap Blog
(Traduction : goofy, lyn, GregR, Britz, Sphinx + anonymes)

Avez-vous reçu un courrier électronique comme celui-là (cf image ci-dessus) ?

Nous ne pouvons vous garantir que vous pourrez disposer de vos cartes. Nous vous recommandons vivement de migrer vers la version 3 de Google Maps avant le 19 novembre.

Oui, Google Maps a décidé de fermer sa vieille API JavaScript de Maps (v2). Ils vous conseillent de passer beaucoup de temps à ré-écrire votre code pour passer à la nouvelle API v3.

Mais pourquoi ne pas utiliser ce temps pour passer à un meilleur service ?

OpenStreetMap (OSM) est une carte créée par des experts, à savoir les habitants mêmes du territoire qu’ils cartographient. On y trouve les sentiers pédestres et les pistes cyclables, les canaux, les espaces verts et les espaces publics, de même que toutes les routes et les chemins de fer. Elle est continuellement mise à jour : pas besoin d’attendre le prochain passage de la voiture Google. Pas étonnant que Foursquare, Github et Mapquest aient déjà opté pour OSM.

Passer de Google Maps à OpenStreetMap est plus facile que vous ne le pensez. Si vous vous êtes déjà confronté à l’ancienne API de Google Map, vous allez trouver en notre équivalent, Leaflet, une bouffée d’air frais. Son interface douce et agréable vous permettra de mettre mieux en valeur l’apparence de votre site, et l’application mobile est aussi fluide que l’application native.

Si vous souhaitez aller plus loin, OpenStreetMap vous permet de créer une belle carte, personnelle, à partir de nos données. Vous n’êtes pas limité au seul style Google, que tout le monde utilise. Puisque les sources sont libres et ouvertes, vous n’avez pas à payer quoi que ce soit pour accéder à des services « premium ».

Comment franchir le pas ? Le site switch2osm.org, géré par la communauté OpenStreetMap, fournit des conseils pour passer à OpenStreetMap. Les sections « The Basics » (NdT : Premiers pas) et « Using Tiles » (Utiliser des tuiles) vous permettront de transformer votre code JavaScript pour qu’il fonctionne avec OSM. Ce site est également utile pour trouver toutes les informations nécessaires à la création de cartes personnalisées.

Au bout du compte, OpenStreetMap est beaucoup plus qu’une solution alternative à l’API Google Maps. Nous offrons quelque chose de différent : un accès libre et ouvert aux données cartographiques brutes. Cela permet aux développeurs de débrider leur créativité et d’innover un maximum, en allant beaucoup plus loin qu’une simple intégration d’une carte dans un site web. Cerise sur le gâteau : plus on utilise OSM sur des sites web, plus les cartes seront vues des utilisateurs et plus les contributeurs à ce travail de cartographie collaborative seront nombreux ; au final, la carte, créée par la communauté, devient de plus en plus précise.

Utiliser OpenStreetMap, c’est défendre et promouvoir ce projet et ainsi nous aider dans notre mission bénévole : créer la carte du monde la plus ouverte et la plus riche qui soit.

switch2osm.org

Robert Douglas et sa femme pianiste Kimiko Ishizaka sont à l’initiative d’un magnifique projet : libérer la musique classique pour la mettre directement dans le domaine public (enregistrements et partitions).

En effet, même si les auteurs sont généralement depuis longtemps dans le domaine public, les enregistrements eux ne le sont pas et sont soumis au strict copyright (idem pour les partitions qui appartiennent à leurs éditeurs).

Je vous invite à parcourir l’article Wikipédia Open Goldberg Variations pour en savoir plus. Une première campagne a été menée avec succès en 2012 pour y enregistrer les Variations Goldberg de Johann Sebastian Bach. Et le résultat est là : des enregistrement (en haute qualité et pas seulement en mp3) et des partitions mis à la disposition de tous.

On notera que cette campagne a été financée par crowdfunding (financement participatif). Nous sommes de plus en plus nombreux à adhérer à cette idée : payer une fois pour que ce soit directement mis dans le pot des biens communs.

Si vous voulez écouter Kimiko Ishizaka jouer du Bach, je vous invite à voir cette vidéo YouTube réalisée cet été lors du festival OHM. Détente garantie…

Or une seconde campagne vient de démarrer, toujours sur le même modèle et toujours Bach : l’enregistrement du Clavier bien tempéré. Cette campagne s’appelle subtilement Ba©h to Bach

Cette campagne est elle aussi déjà couronnée de succès puisque la somme (non négligeable) à atteindre vient d’être dépassée. Mais le projet veut aller plus loin. en direction de l’accessibilité et des malvoyants, et ce grâce aux logiciels libres. Il nous explique cela ci-dessous et vous invite à continuer à participer financièrement à la campagne si vous jugez que cela le mérite.

Ce projet exemplaire a tout notre soutien et démontre une fois de plus qu’ensemble nous pouvons déplacer des montagnes et agir pour un monde meilleur…

Faire de la musique libre sur KickStarter et doubler le nombre de partitions pour aveugles

Kickstarting open source music and doubling the number of scores for the blind

Robert Douglass – 14 ocotbre 2013 – OpenSource.com
(Traduction : Penguin, Isammoc, Scailyna + anonymes)

La sérendipité m’a été un jour décrite comme le fait de chercher une aiguille dans une meule de foin et de trouver la fille du fermier. Dans le cas du projet Open Well-Tempered Clavier (NdT: la libération du Clavier bien tempéré de Bach), cela fut plutôt : essayer de faire une version open source de la musique de Bach, et découvrir que les musiciens aveugles affrontaient un manque critique de partitions en braille disponibles pour leurs études. Or, contrairement aux deux siècles précédents, on peut désormais faire quelque chose pour résoudre ce problème, en utilisant les logiciels libres.

Faire de la musique libre avec des outils libres tels que MuseScore est le but premier du projet Open Well-Tempered Clavier, et c’est ce qui a attiré Eunah Choi, une professeur en Corée du Sud, à devenir un backer (souscripteur) sur KickStarter. Cela a conduit à une discussion informelle par e-mail assorties de questions triviales « Êtes-vous une pianiste ? » et « Faites-vous des études dans la musique ? ».

La réponse qu’Eunah nous a envoyée est déchirante. Elle a enregistré un message vidéo de l’email que vous pouvez voir ci-dessous, mais en résumé, elle est malvoyante, et il n’y a pas assez de partitions en braille pour constituer une étude sérieuse du piano. Au bout du compte, elle a abandonné la mort dans l’âme son rêve de devenir une pianiste professionnelle.

—> La vidéo au format webm
—> Le fichier de sous-titres

Cette révélation a été très perturbante pour moi et pour l’équipe de MuseScore. Nous avions prévu de rendre la musique accessible et nous avions manifestement échoué pour le groupe de personnes qui en avait le plus besoin.

Nous nous sommes donc demandés : « Est-ce que cela peut être arrangé ? » La réponse à cette question est très clairement « Oui » ! MuseScore a depuis longtemps adopté des standards libres, comme MusicXML, et il y a les bibliothèques libres, Freedots et music21, qui tentent de convertir MusicXML en braille, et qui sont adaptés à la lecture sur des appareils comme ceux qu’Enuah utilise dans ces videos. Mais ces deux bibliothèques ne sont pas terminées et nécessite plus de développement.

Armé de cette nouvelle information, le projet Open Well-Tempered Clavier a élargi sa mission et défini de nouveaux objectifs sur Kickstarter. En supposant qu’il aura un financement suffisant, l’équipe ne proposera pas seulement des partitions et des partitions du Clavier bien tempéré de Bach dans le domaine public (le but initial), mais aussi une version en braille. Puis nous créerons une version en braille des Variations Goldberg de Bach, qui a été publiée en 2012. Grâce à ces efforts, il nous sera possible de créer un service web accessible et libre pour automatiser la chaîne de conversion de partitions MuseScore et MusicXML en braille et de convertir automatiquement plus de 50 000 partitions de la bibliothèque MuseScore.com.

Étant donné qu’il existe à l’heure actuelle moins de 20 000 titres disponibles en braille, l’ajout de 50 000 titres supplémentaires serait véritablement significatif. Abaisser la barrière de la conversion pour les partitions numériques, et fournir les outils sous la forme de logiciel libre, garantit que ce nombre va continuer de croître.

C’est la responsabilité des voyants de fournir des copies de nos trésors culturels dans des formats pouvant être lus par les aveugles et les malvoyants. Les logiciels libres nous aideront à réaliser ce devoir.

» Pour participer à la campagne du projet

Crédit photo : Rodriago (Creative Commons By)

Ce que j’aime chez Mozilla va bien au-delà du code… Le témoignage enthousiaste et caractéristique d’un contributeur.

Ce ne sont pas les développeurs sur des projets non libres qui peuvent en dire autant.

Ce que j’aime chez Mozilla

What I Love about Mozilla

Mihnea Dobrescu-Balaur – 6 octobre 2013 – Blog personnel
(Traduction : Asta, Penguin, goofy, Isammoc, FF255, nclm, GregR, greygjhart, Isammoc)

Je me suis pas mal impliqué pour Mozilla ces derniers temps et, entre mon dernier stage et le MozSummit de ce week-end, plusieurs pensées ont commencé à germer à propos de ce que j’aime le plus à son sujet. Ne perdez pas de vue que ces mots traduisent uniquement mes impressions.

Quand je parle de Mozilla aux gens, ils pensent en général « ah, Firefox ! ». Même si Firefox est notre projet le plus populaire actuellement, Mozilla représente bien plus que ça ; voici pourquoi j’écris cela.

Tout commence avec notre mission qui, comme Mitchell l’a expliqué au Summit, peut être réduite à trois principes de base :

1. Le Web doit être ouvert : Internet est une source d’information publique qui doit être ouverte et accessible à chacun dans le monde entier.
2. Le Web doit être interopérable : les gens ne doivent pas être enfermés dans un écosystème et doivent pouvoir utiliser la technologie qu’ils préfèrent pour accéder à Internet.
3. Le Web doit être nôtre : les gens doivent avoir la possibilité de façonner leur expérience d’Internet et de contribuer à son contenu sans demander la permission à une instance centrale.

Il n’y a rien ici concernant les performances de JavaScript, le temps de démarrage des app, la fluidité du défilement ou d’autres mots à la mode ; bien que ceux-ci ne soient clairement pas ignorés, cela montre que Mozilla a des priorités différentes.

À chaque fois que je vois une démo ou que je lis un sujet sur un nouveau projet en cours, je suis impressionné de voir à quel point les gens recherchent la standardisation et maintiennent le choix de l’utilisateur au premier plan à tout moment. Cela montre encore que nous ne sommes pas dans une course à la fonctionnalité, essayant de nous démarquer au travers de fonctionnalités que les autres n’ont pas. Si vous avez fait attention aux principes, vous saurez que c’est en fait impensable… Le Web doit être interopérable, vous vous souvenez ?

La mission est ce qui guide la communauté. Je pense que nous avons là une communauté fantastique : développeurs, designers, testeurs, reps (NdT : des « représentants » Mozilla bénévoles qui organisent des événements), travaillant tous ensemble pour s’assurer, et là encore pour paraphraser Mitchell, qu’Internet soit ce que le monde a besoin qu’il soit. Contrairement à d’autres projets, où la communauté environnante ne joue qu’un (petit) rôle de soutien mineur, Mozilla telle qu’on la connaît ne serait pas pareille sans sa cohorte de volontaires.

Outre Firefox, nous travaillons sur d’autres projets qui rendent le Web plus accessible et le font avancer. Firefox OS et Webmaker me viennent à l’esprit. Firefox OS rapproche Internet des personnes qui n’ont pas actuellement de smartphone. En même temps, il fait avancer les technologies Web en procurant un support semblable à celui que les développeurs sur des plateformes fermées, propriétaires à travers des applications natives peuvent avoir. Webmaker a pour objet de forger notre Internet – il permet aux gens de contribuer au Web avec leur propre contenu.

Avec sa mission, ses super volontaires et ses projets tournés vers la communauté, Mozilla est différente. Elle est spéciale. C’est quelque chose que beaucoup n’auraient pas pensé possible. Il n’y a pas si longtemps, personne n’aurait pensé qu’un logiciel libre, gratuit et open source puisse atteindre une part de marché significative. Firefox l’a fait et c’est grâce à son influence déterminante que nous en sommes arrivés à disposer d’autres choix que seulement Internet Explorer pour naviguer sur le Web.

Notre communauté démontre qu’un groupe de gens dispersés à travers le monde peut faire du beau travail ensemble. Firefox OS amène le Web encore plus loin, plus proche des terminaux mobiles de plus en plus populaires. Tout cela et bien d’autres choses encore est réalisé en toute transparence par des contributeurs passionnés. Comment ne pas l’aimer !?

Crédit photo : Beyond the Code