1

Brevets logiciels : la position de Donald Knuth en 1995

En 1995, l’un des plus brillants informaticiens au monde, le professeur Donald Knuth, écrivait une lettre au bureau américain des brevets (USPTO) que nous vous proposons traduite ci-dessous.

Les arguments pour refuser les brevets sur le logiciel sont déjà là et fort bien exposés. Ce qui n’empêche pas de devoir se battre régulièrement depuis contre cette néfaste tentation.

No Software Patents

Lettre à l’Office des Brevets, par le professeur Donald Knuth

Donald Knuth – 1995
(Traduction : rocherd, audionuma, r0u, FMy1, simon, Omegax)

Letter to the Patent Office From Professor Donald Knuth

Chers membres de la commission,

De même que beaucoup d’autres chercheurs en informatique, je voudrais vous demander de reconsidérer la politique actuelle de cession de brevets sur les processus informatiques (NdT : computational processes). J’ai pu en effet constater une inquiétude considérable parmi la communauté des chercheurs en informatique, la peur que les décisions des tribunaux spécialisés dans le droit des brevets et du Bureau des Brevets et des Marques Déposées (NdT : Patent and Trademark Office) rendent la vie des programmeurs bien plus difficile.

Durant la période 1945-1980, il était communément admis que les lois sur les brevets n’étaient pas appliquables au logiciel. Cependant, certaines personnes auraient apparemment obtenues des brevets sur des algorithmes d’une importance capitale — par exemple, la compression Lempel-Ziv et le chiffrement par clé RSA publique — et aujourd’hui ils interdisent en toute légalité aux autres programmeurs d’utiliser ces algorithmes.

C’est un changement radical par rapport aux pratiques précédentes qui ont rendu possible la révolution informatique, et je crains que ce changement ne soit dommageable pour la société. Cela aurait pu avoir un fort impact négatif sur mon propre travail : par exemple, j’ai développé un logiciel appelé TeX qui est actuellement utilisé pour la conception de plus de 90 % des livres et revues de mathématiques et physique mais aussi de centaines de milliers de rapports techniques dans toutes les disciplines scientifiques. Si les brevets logiciels avaient été monnaie courante en 1980, je n’aurais jamais pu créer un tel système, ou penser à le créer, ni même imaginer que quelqu’un puisse le faire.

On me dit que les tribunaux essaient de faire une distinction entre les algorithmes mathématiques et les algorithmes non-mathématiques. Pour un informaticien, c’est un non-sens, car chaque algorithme est un objet mathématique s’il en est. Un algorithme est un concept abstrait sans relation avec les lois physiques de l’Univers.

Il n’est pas non plus possible de faire la distinction entre des algorithmes « numériques » et « non-numériques », comme si les nombres étaient en quelque sorte différents des autres formes d’information exacte. Toutes les données sont nombres, et tous les nombres sont données. Les mathématiciens travaillent bien plus avec des entités symboliques qu’avec des nombres.

L’idée d’adopter des lois affirmant que certains algorithmes sont mathématiques et d’autres ne le sont pas me parait tout aussi absurde que la tentative de l’Assemblée Générale de l’Indiana, au XIXème siècle, d’adopter une loi stipulant que le rapport de la circonférence d’un cercle à son diamètre est exactement 3 ou que l’Église médiévale décidant que le Soleil tourne autour de la Terre. Les lois des Hommes peuvent être significativement utiles, mais pas lorsqu’elles contredisent les vérités fondamentales.

Il y a bien longtemps, le Congrès avait judicieusement décidé que les objets mathématiques ne pouvaient pas être brevetés. Il est certain que personne ne pourrait utiliser les mathématiques s’il fallait payer un droit de licence à chaque utilisation du théorème de Pythagore. Les idées de base de l’algorithmique que certaines personnes poussent à faire breveter sont si fondamentales, que le résultat menace d’être similaire à ce qui arriverait si on autorisait les auteurs à breveter les mots et expressions. Les romanciers ou les journalistes ne pourraient plus écrire sans que leurs éditeurs n’obtiennent les permissions des propriétaires des mots. Les algorithmes sont au logiciel ce que les mots sont pour les écrivains, parce qu’ils sont les briques fondamentales nécessaires pour construire quelque chose d’intéressant. Qu’arriverait-il si les juristes pouvaient breveter leurs méthodes de défense ou si les juges de la Cour Suprême pouvaient breveter leurs jurisprudences ?

J’ai bien conscience que les tribunaux de brevets essaient de faire de leur mieux pour servir la société. Le Bureau des Brevets a ainsi admirablement rempli cette mission en ce qui concerne les aspects de technologies reposant sur les lois concrètes de la physique plutôt que les lois abstraites de la pensée. Je suis moi-même titulaire de quelques brevets sur des dispositifs matériels. Mais je pense fermement que cette récente tendance à breveter les algorithmes ne profite qu’à un petit nombre d’avocats et d’inventeurs alors qu’elle entrave la grande majorité de personnes qui veulent faire des choses utiles avec les ordinateurs.

Quand je songe aux programmes informatiques dont j’ai besoin quotidiennement pour travailler, je ne peux m’empêcher de réaliser qu’aucun d’entre eux n’existerait aujourd’hui si les brevets logiciels avaient prévalu dans les années 60 et 70. Changer les règles aujourd’hui aura pour conséquence de geler le progrès à peu près à son niveau actuel. Si cette tendance se confirme, la seule alternative pour la majorité des brillants développeurs américains de logiciels sera d’abandonner ou émigrer. Les États-Unis perdront alors leur position dominante.

Merci de faire votre possible pour inverser cette tendance alarmante. Il existe de bien meilleures façons de protéger les droits de propriété intellectuelle des développeurs de logiciels que de les empêcher d’utiliser des briques fondamentales.

Sincèrement,
Donald E. Knuth
Professeur émérite




Geektionnerd : Enseignement du code à l’école

14-07-22_-_Enseignement_du_code

Gee est en vacances, on fait ce qu’on peut, soyez indulgents 😉

Crédit : Simon Gee Giraudot, Christophe Masutti et Luc Didry (Creative Commons By-Sa)




Geektionnerd : Les sources de MS-DOS

geektionnerd_187-1_simon-gee-giraudot_cc-by-sa.jpg

geektionnerd_187-2_simon-gee-giraudot_cc-by-sa.jpg

Source :

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)




Rencontre avec ALGEM, Application Libre de Gestion d’École de Musique

ALGEM

Vous participez ou administrez directement une école de musique ? Ou plus généralement vous vous occupez d’un lieu associatif qui doit organiser la gestion des plannings, des adhérents et des contacts, la réservation des salles, la planification des cours, le prêt du matériel… ?

Sachez qu’il existe une excellente application développée depuis plus de dix ans par deux passionnés de musique et d’informatique !

Le logiciel s’appelle ALGEM (le L c’est donc pour Libre) et il méritait assurément une petite mise en avant.

Rencontre avec Bruno Mauguil (au centre sur la photo) et Jean-Marc Gobat (à droite) qui travaillent tous deux à Musiques Tangentes (Malakoff) d’où l’aventure ALGEM a vu le jour.

img_2802.jpg

Interview ALGEM

Bonjour Bruno et Jean-Marc, pouvez-vous vous présenter succinctement ?

426285_145343322250790_1790613950_n.jpgJean-Marc : agrégé d’éducation musicale et diplômé de l’école d’ingénieurs du CNAM de Paris, j’ai la chance de pouvoir pratiquer au sein de Musiques Tangentes mes deux passions que sont la musique et l’informatique. Je participe au développement d’ALGEM depuis quelques années déjà et intervient dans l’école en tant que professeur de M.A.O. Je suis aussi membre fondateur du groupe de fusion World « Transbohêm ».

Bruno : à l’origine musicien de Jazz, j’ai créé Musiques Tangentes à l’âge de 20 ans au milieu d’un grand vide intersidéral : pas de locaux de répétition, pas d’école de musiques actuelles… Après avoir fondé l’école, épaulé de quelques furieux musiciens, l’informatique nous a permis de structurer ce milieu embryonnaire. J’ai tout de suite compris l’immense intérêt de ce nouvel outil : création, gestion, bureautique, etc. Après m’être débattu sur Prologue (système d’exploitation français de Bull) puis fait un court et malheureux passage sur Windows, je participe aux balbutiements du Libre grâce à la rencontre providentielle d’Eric. C’est la révolution ! Bien que je ne sois pas du tout informaticien, je ne jure depuis que par l’Open Source. Cela fait maintenant 15 ans que nos outils bureautique sont sous Linux. La musique viendra plus tard sur ce système et en partie seulement. ALGEM est né du fait de l’absence totale d’outil de gestion pour notre activité. La suite reste à écrire….

Alors ALGEM c’est quoi ?

Jean-Marc : strictement parlant, ALGEM est l’acronyme d’Application Libre de Gestion d’Ecole de Musique. C’est au départ un logiciel de gestion dédié aux écoles de musiques actuelles. Axé sur la gestion de plannings et de contacts, il s’est enrichi au cours des années et peut très bien convenir aujourd’hui à d’autres types de structures.

Quelle est la répartition des rôles entre vous deux ?

Jean-Marc : je suis chargé du développement, de la maintenance chez nos partenaires et de tous les aspects techniques liés à l’installation, le fonctionnement et les rapports d’erreurs signalés par nos utilisateurs.

Bruno : je suis responsable de l’Association et initiateur du projet. Je suis donc à la fois maître d’œuvre et maître d’ouvrage, responsable du cahier des charges, définissant les grandes lignes et les besoins, et de plus en plus concerné par les problèmes de déploiement. Je joue beaucoup aussi le rôle de bêta-testeur, avec l’ensemble de l’équipe, et suis bien sûr utilisateur au quotidien depuis maintenant plus de 10 ans.

C’est parti d’un besoin interne ? Il n’existait rien de similaire sur le marché ?

Jean-Marc : effectivement, il n’y avait rien de comparable sur le marché à l’époque de sa mise en chantier. Les quelques solutions existantes, très coûteuses de surcroît, étaient réservées aux utilisateurs de Windows et ne correspondaient pas aux besoins des écoles de musiques actuelles. Il fallait donc choisir entre une solution bancale ou le développement d’un logiciel en interne. C’est ce dernier choix qui a été fait, grâce à la participation d’Eric. Ses compétences en Java, langage à l’époque en pleine expansion, lui ont permis en quelques mois de fixer l’ossature du logiciel et de le rendre opérationnel dans nos locaux.

Quand avez-vous décidé d’en faire un logiciel libre et pourquoi ? Et avez-vous constaté une amélioration dans la diffusion et participation du projet ?

Jean-Marc : depuis les débuts, Musiques Tangentes s’investit dans le libre, en privilégiant les systèmes et logiciels Open Source et les applications sous Linux. Il était naturel avec ALGEM d’ajouter une pierre à l’édifice. Comme il a fallu pas mal de temps pour refaçonner l’application, réorganiser les sources et produire quelque chose de plus cohérent, ce passage n’a pu se faire qu’assez récemment, début 2012 (les sources sur GitHub). C’était aussi l’objectif/rêve de Bruno, celui de pouvoir partager un outil avec les confrères et de contribuer à la communauté du libre.
La diffusion du logiciel est encore assez réduite, mais de nombreuses demandes nous ont été faites depuis les derniers mois. Et nous avons constaté un regain d’intérêt depuis le début de l’année scolaire et la publication sur Framasoft.

vue_generale.png

Le logiciel évolue comme vous voulez ? Résistez-vous au « cloud » ?

Jean-Marc : beaucoup de projets en cours, oui. Des fonctionnalités en chantier : gestion de stages, importation de carnets d’adresse, pré-réservation en ligne, etc. Quant au « Cloud », s’il présente indéniablement des avantages, comme la simplification des procédures pour les novices, son adoption à grande échelle par les entreprises dominantes symbolise pour nous une certaine forme de retour au Minitel, comme l’avait remarqué à juste titre Benjamin Bayart dans sa fameuse conférence. S’en remettre à des entreprises comme Google, Facebook, Apple ou Microsoft, c’est un peu renier l’Internet des origines, décentralisé et pluriel. Afin de répondre aux besoins d’une certaine frange de nos utilisateurs, nous avons essayé néanmoins avec Algem Webstart de concilier les deux mondes : déployer localement l’application tout en profitant de l’hébergement en ligne.

Dans combien de structures ALGEM est-il déployé ? Elles s’occupent toutes de musique ?

Jean-Marc : Officiellement, une demi-douzaine de structures, dont deux à Toulouse et à Tours avec lesquelles nous sommes en relation très étroite. Cela va de la salle de répétition au salon de coiffure ! Donc, pas nécessairement ciblé école de musique. Officieusement, une trentaine de structures nous ont déjà demandé une version d’ALGEM pour leur usage personnel.

C’est dans le cadre de Musiques Tangentes que vous avez développé ALGEM. Pouvez-vous nous en dire plus sur ce lieu, son histoire, les services proposés ?

Bruno : Musiques Tangentes est un centre « musiques actuelles » : apprentissage de loisir, centre de formation professionnelle, studio de répétition (collectif et individuel), studio d’enregistrement, accompagnement de projet et un peu de diffusion (amateur et professionnel). C’est aussi un lieu de création et d’accueil de résidence ou d’insertion professionnelle. C’est une structure pionnière, née dans le squat de la rue des Caves à Sèvres. Nous fêtons cette année nos 35 ans d’existence et Musiques Tangentes est ouverte à tous (à partir de 3 ans), débutant ou confirmé, amateur ou professionnel. Un tiers de notre activité s’effectue aussi hors les murs (intervention en temps scolaire, en périscolaire, en centre spécialisé type IME, en colonie de vacance, en crèche, en entreprise…), partout ou l’on peut faire de la musique… « PLUS DE BRUIT », la Mano Negra est passée par chez nous, c’est un lieu d’apprentissage, de rencontres et d’échanges. Bref, un berceau d’utopies où l’on peut encore rêver et jouer sans contraintes !

IMG_2943.jpg


Il me semble que vous y proposez un studio d’enregistrement « full libre » ?

Jean-Marc : nous utilisons depuis longtemps des distributions Linux spécialisées dans l’audio-numérique, comme 64Studio, Ubuntu Studio, ou plus récemment Tango Studio. Ardour est installé dans notre rack informatique et nous permet de réaliser des enregistrements sous ces systèmes, grâce à la compatibilité matérielle de notre carte RME MADI 64 canaux. Bien que nous fournissions aussi des prestations sur Pro Tools, le logiciel de référence dans de nombreux studios, nous ne pouvons qu’encourager l’usage de solutions libres. Musiques Tangentes est pratiquement la seule structure à proposer de tels services dans un environnement résolument professionnel : console numérique SONY DMX-R100, station de travail Intel i7 64 bits en dual boot, enceintes A2T. La demande est encore infime mais il n’est pas interdit de penser que l’utilisation d’un logiciel comme Ardour soit à l’avenir de plus en plus pertinente, face à une concurrence peu réactive et très coûteuse.

Est-ce que vous en profitez pour sensibiliser vos membres mélomanes aux licences libres ? Y en a-t-il qui ont fait le choix des licences Creative Commons pour leurs créations ?

Jean-Marc : j’ai moi-même édité l’album « Déserts » de Transbohêm sous licence Creative Commons. D’autres adhérents et membres de l’équipe administrative ont aussi choisi cette licence pour leurs réalisations. Pour un indépendant désireux aujourd’hui d’éditer sa musique, les licences libres présentent une belle alternative face aux fourches caudines de la SACEM.

Bruno : Musiques Tangentes est membre de « Libre Accès » et à ce titre nous avons vivement encouragé nos adhérents à utiliser des licences libres. Vous trouverez de nombreux articles à ce sujet sur notre blog. De plus, des ateliers découverte sont organisés régulièrement autour de ce thème.

Et pour finir, un appel à bonne volonté pour ALGEM ?

Jean-Marc : tout le monde est bienvenu : relecteurs de code, testeurs, spécialistes Java. Nous invitons d’autre part toutes les structures utilisant le logiciel à nous donner leur avis ou nous suggérer des améliorations possibles. Nos propositions de journées de formation restent d’ailleurs toujours d’actualité et nous encourageons tous les utilisateurs à les suivre afin de participer aux avancées d’ALGEM et de pérenniser son développement dans les années futures.

Bruno : nous en sommes encore à l’aube de l’engagement communautaire autour de ce projet et nous espérons que de nombreux utilisateurs et programmeurs nous rejoindrons prochainement . Une première rencontre entre tous les acteurs concernés sera d’ailleurs proposée très bientôt.

-> ALGEM – Pour tout contact : info@algem.net

IMG_8460.JPG__Rj7989_.jpg




Conseils pour bien préparer son hackathon autour d’un projet libre

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.

 

OpenHatch team

 

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 . 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 .

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



Programme d’informatique dès l’école primaire ?

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.

Informatique à l'école - cc-by-sa - Lupuca

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)




Demain la culture libre direct depuis Unity d’Ubuntu ? #BitTorrent

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 ?

Unity Ubuntu Torrent

Unity Ubuntu Torrent

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.




Exemplaire libération du jeu CodeCombat

« 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…

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 !

CodeCombat

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é.

CodeCombat

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.