« Android représente une étape majeure vers un téléphone portable libre qui soit contrôlé par l’utilisateur, mais il y a encore beaucoup de chemin à parcourir. Les hackers travaillent sur Replicant, mais c’est un gros travail de rendre un nouveau modèle compatible, et il reste encore le problème du micrologiciel. Même si les téléphones Android d’aujourd’hui sont considérablement moins mauvais que les smartphones d’Apple ou de Windows, on ne peut pas dire qu’ils respectent vos libertés. »

Ainsi se termine l’article de Richard Stallman consacré à Android et la liberté des utilisateurs. On y évoque donc le projet Replicant qui vise à produire un dérivé entièrement libre du système d’exploitation de Google.

Or il se trouve que nous avons la chance d’avoir l’un des développeurs du projet parmi les membres traducteurs de Framalang. Il eut été alors dommage de ne pas en profiter pour en savoir plus et comprendre la difficulté qu’il y a à tenter de libérer totalement un téléphone portable.

On notera que ce développeur est encore lycéen, ce qui fournit au passage un excellent témoignage d’une jeunesse qui, ayant découvert le logiciel libre, n’a plus forcément envie de passer tout son temps sur Facebook 🙂

Le projet Replicant, présenté par le développeur PaulK

Présentation de PaulK, un des deux développeurs du projet Replicant

Je m’appelle Paul et me présente souvent sous le pseudo « PaulK ». Je suis actuellement lycéen (en filière scientifique) et utilise du logiciel libre depuis 2008.

J’ai commencé avec l’utilisation de Ubuntu 8.04, en dual boot avec Windows à l’époque. En décembre 2009, j’ai décidé de passer sur Fedora, qui respectait mieux ma vision de l’informatique libre (en mettant en avant la liberté et non le seul caractère « Open Source »). Déjà à l’époque, j’étais un fervent lecteur du framablog et enthousiaste des projets de Framasoft. J’ai progressivement commencé à appendre la programmation (en C) et me suis finalement débarrassé de mes partitions Windows. J’ai aussi commencé à contribuer à certains projets proches du monde du logiciel libre, comme OpenStreetMap.

Début 2010, j’ai commencé à m’intéresser aux différentes solutions des plus libres dans le domaine de la téléphonie mobile. Je suis finalement tombé sur le site web du projet Replicant et suis allé jeter un œil sur le canal irc du projet (#replicant sur irc.freenode.net) : j’y ai trouvé le développeur principal du projet, qui, connaissant très bien la question m’a exposé les différentes solutions existantes. J’ai opté pour le Neo FreeRunner, le téléphone « le plus libre » (100% de logiciel libre tournant sur le CPU) avec à la fois une communauté francophone et internationale dédiée au projet. Je l’ai utilisé comme téléphone principal mais l’ai endommagé (avec mon fer à souder) par mégarde , après de nombreux mois d’utilisation. Pour trouver un successeur, je suis revenu sur le salon IRC du projet Replicant pour finalement choisir un HTC Dream, sur lequel j’ai installé Replicant. J’ai ensuite commencé à vouloir aider au développement du projet, après avoir compilé mes premières images du système.

En effet, depuis que j’ai commencé à utiliser GNU/Linux, mon intérêt pour la programmation n’a cessé de croitre et j’ai finalement manipulé un certain nombre de languages : C, Perl, Javascript, Lua… Contribuer au projet Replicant m’a, entre autres, permis d’apprendre les bases de Git, de comprendre et modifier des drivers du noyau, de mettre en application très concrète mes connaissances en C…

Depuis plusieurs mois, je concentre mon attention sur le support du Nexus S, le dernier téléphone de Google/Samsung.

Présentation du projet Replicant

Le projet Replicant vise à produire un dérivé entièrement libre d’Android, le système d’exploitation destiné au matériel embarqué (et originellement aux téléphones) produit par l’« Android Open Source Project » (désigné par AOSP) , dirigé par l’« Open Handset Alliance », qui est menée par Google. La version d’Android telle que produite par l’AOSP contient du code provenant de divers horizons et distribué sous diverses licences : du code sous GNU GPL, du code sous BSD et par exemple pour ce qui a été écrit par l’AOSP, du code sous licence Apache 2. A l’exception de quelques micro-logiciels (firmwares), le code d’Android tel que fourni par l’AOSP est libre.

On peut donc télécharger ce code source, éventuellement retirer ces firmwares et le compiler afin d’obtenir un système totalement libre. Le problème principal ici est qu’une telle version d’Android serait absolument inutilisables sur un téléphone. Seul l’émulateur Android (celui présent dans le « SDK ») fonctionnerait sans poser de soucis.

En effet, la grande majorité des téléphones fonctionnant sous Android nécessitent, à un moment ou à un autre, des librairies, programmes ou firmwares non-libres. La quasi-totalité de ces composants non-libres touchent directement à la communication avec le matériel : du traitement des données en provenance des accéléromètres jusqu’au composant en charge de dialoguer avec le modem (ce qui gère toutes les fonctions liées à la téléphonie, à l’envoi des messages, à la connexion 3G, etc).

Le projet Replicant a donc deux objectifs :

• fournir un système basé sur Android entièrement libre
• écrire des remplacements aux composants non-libres afin de pouvoir utiliser le téléphone avec Replicant « pour de vrai ».

Chaque appareil ayant ses particularités, son propre matériel, il faut un noyau particulier par appareil, une image du système avec les librairies et les configurations adaptées par appareil, ce qui demande de faire le travail séparément pour chaque appareil : il n’y a pas de remplacement miracle qui marcherait avec tous les appareils Android d’un coup lorsqu’il s’agit de fonctions bas-niveau touchant au matériel. Ceci rend donc le travail très long et demande aussi au développeur de posséder chaque téléphone sur lequel il travaille.

L’état actuel du projet

Pour l’instant, le nombre de téléphones supportés par le projet Replicant est relativement réduit : en effet, seuls deux développeurs font partie du projet, mêmes si des aides extérieures sont souvent là pour participer au développement. A l’heure actuelle (fin 2011), les modèle suivants sont utilisables : HTC Dream, HTC Magic, Google Nexus One (nécessite des firmwares non-libres pour que l’audio fonctionne) et le Google Nexus S n’est pas encore prêt dans le sens où les fonctions liées à la téléphonie n’ont pas encore été libérées (mais le travail est en cours).

La liste plus détaillée des fonctionnalités présentes avec Replicant pour chaque téléphone est disponible sur cette page.

De plus, le projet dispose d’un site web, où sont postées les dernières nouvelles du projet, d’une liste de diffusion et d’un canal IRC.

Petit historique du projet

Replicant n’est pas un projet très ancien : démarré à l’été 2010 afin de rassembler plusieurs initiatives isolées visant à produire une version entièrement libre dérivée d’Android pour le premier « Google phone », le HTC Dream, le projet a vite abouti à l’écriture de code pour remplacer les parties non-libres : le premier composant non-libre à avoir été remplacé a permis à l’audio de fonctionner sans composants non-libres. L’idée de créer un dépôt libre d’applications, s’accompagnant d’un logiciel client pour Android (et donc Replicant) a également été envisagé assez rapidement, mais cette première tentative n’a pas abouti. Plus tard, le projet Fdroid viendra combler ce manque, fournissant un dépôt d’applications libres faisant directement office de remplacement à l’« Android market ». La partie gérant la communication avec le modem (dite « RIL ») a ensuite été remplacée par du code libre, rendant ainsi le téléphone utilisable. Une librairie pour le GPS a aussi été adaptée à partir de code libre destiné à un autre téléphone. L’horizon du projet s’est également élargie avec le début du port de Replicant sur le Nexus One, qui a d’ailleurs été offert au développeur principal par Google, preuve de leur intérêt ou curiosité pour le projet Replicant. Maintenant, c’est le Google Nexus S qui est en train d’être porté sur Replicant (mais aussi sur GNU/Linux, au sein du projet SHR).

Le problème des firmwares malveillants, ou le problème principal auquel Replicant ne peut pas apporter de solutions

Si nous nous efforçons de produire des remplacements libres pour la plupart des composants non-libres présents les version d’Android distribuées avec les téléphones, il y a certains composants qu’il nous est (pour l’instant) impossible de remplacer. C’est en effet particulièrement le cas de certains firmwares, tels que le logiciel (non-libre) qui est exécuté sur le modem. Aucun des développeurs du projet n’a les compétences techniques pour réaliser une alternative libre à ce composant et de toute façon, il ne serait pas légal d’exécuter un tel logiciel sur les réseaux des opérateurs. En effet, ceux-ci ne seraient pas certifiés. Le seul projet de remplacement libre du logiciel contenu dans le modem se nomme OsmocomBB et devrait fonctionner sur un nombre très réduit de téléphones, incluant le Neo FreeRunner (qui n’a par défaut pas de logiciel libre sur le modem mais bien un logiciel propriétaire). Pour plus de détails, reportez-vous à la page présentant les aspects légaux du projet.

Si le logiciel exécuté sur le modem est forcément non-libre, alors tout ce qui est connecté directement au modem est nécessairement compromis : si le GPS est attaché au modem et non au processeur principal, le GPS est contrôlé par un logiciel non-libre qui, s’il gère par exemple également la connexion de données (3G), ce qui est le cas pour un modem, pourra éventuellement recevoir ou envoyer des informations obtenues du GPS, telles que la position très précise de l’utilisateur, à tout moment et sans aucun contrôle possible de la part de l’utilisateur. Ainsi, si le matériel est fait d’une telle sorte, utiliser Replicant sur le processeur n’aidera pas à solutionner ce genre de problème.

Un des freins majeurs au développement de Replicant : l’incapacité d’installer une image non-officielle d’Android sur beaucoup de téléphones

En effet, un nombre très important (pour ne pas dire la majorité) des téléphones Android n’offrent aucun moyen à l’utilisateur d’installer un système non-officiel sur son téléphone. Comme s’il était interdit et impossible de changer le système d’exploitation de son ordinateur. Toutefois, sur certains téléphones, il est possible, d’une manière ou d’une autre, de permettre à l’utilisateur de replacer son système actuel par une autre version, pas nécessairement officielle, d’Android. Cette pratique s’appelle le « rooting » du téléphone. Il s’agit généralement d’exploiter une faille de sécurité présente sur le système Android afin d’obtenir les droits root et ainsi de pouvoir écrire un petit logiciel qui permettra par la suite de remplacer le système d’exploitation du téléphone. D’autres méthodes de « rooting » du téléphone consistent à modifier le chargeur de démarrage (dit « bootloader ») du téléphone afin que celui-ci propose l’installation de nouvelles images (il s’agit des fichiers contenant le système Android, le noyau, etc). Alors que la première technique est souvent sans danger, même si elle va dans la plupart des cas rompre la garantie, la seconde technique peut rendre le téléphone inutilisable : si le chargeur de démarrage est altéré au point de ne plus pouvoir fonctionner, le téléphone ne démarrera plus. Ceci n’est, dans la plupart des cas, pas irréversible mais demandera un matériel adapté et une connaissance spécifique pour remettre le téléphone en état.

Toutefois, la plupart des constructeurs réalisent maintenant qu’il est dans leur intérêt de proposer des chargeurs de démarrage permettant d’installer d’autres systèmes d’exploitation, et encouragent parfois le développement de tels systèmes. Le projet CyanongeMod^[1], dérivé d’Android et sur lequel Replicant se base en est un bon exemple : plusieurs constructeurs tels que Samsung ou Sony Ericsson sont en effet très favorables au développement de CyanogenMod pour leurs téléphones (même s’il ne s’agit pas encore de vendre des téléphones avec CyanogenMod pré-installé).

De plus, les « Google phones », le T-Mobile G1, le Nexus One et le Nexus S sont eux-aussi munis d’un chargeur de démarrage permettant l’installation de systèmes non-officiels.

Android, le système d’exploitation de Google pour la téléphonie mobile, est-il véritablement un logiciel libre ?

C’est la question que s’est posée récemment Richard Stallman dans le colonne du Guardian.

« Presque » pourrait être une réponse optimiste. Mais c’est un presque subtil et complexe qui demande quelques explications et éclaircissements^[1].

Parce qu’ici comme ailleurs, le diable se cache souvent dans les détails…

Android et la liberté des utilisateurs

Android and Users’ Freedom

Richard Stallman – 19 septembre 2011 – GNU.org
Traduction : Sylvain Le Menn – Creative Commons BY-ND

Dans quelle mesure est-ce qu’Android respecte les libertés de ses utilisateurs ? Pour l’utilisateur d’un ordinateur qui chérit la liberté, c’est la question la plus importante à se poser pour tout logiciel.

Dans le mouvement du logiciel libre, nous concevons des logiciels qui respectent les libertés des utilisateurs de sorte que vous comme moi puissiez échapper à l’emprise de ceux qui les dénient. Cela contraste avec l’idée de l’« open source » qui se concentre sur la façon de concevoir le code ; c’est une réflexion différente qui s’intéresse principalement à la qualité du code plutôt qu’à la liberté. Ainsi, le souci principal n’est pas de savoir si Android est « ouvert », mais s’il permet à celui qui l’utilise d’être libre.

Android est un système d’exploitation orienté principalement vers les téléphones portables. Il est constitué du noyau Linux (le noyau de Torvalds), quelques bibliothèques, une plateforme Java, et quelques applications. Sans parler de Linux, le logiciel d’Android versions 1 et 2 a été concu essentiellement par Google. Google l’a sorti sous la licence Apache 2.0, qui est une licence libre permissive sans copyleft.

La version de Linux incluse dans Android n’est pas un logiciel entièrement libre puisque qu’il contient des morceaux de code non libres (des « binary blobs »), tout comme la version de Torvalds de Linux, dont quelques-uns sont réellement utilisés dans des machines tournant sous Android. Les plateformes Android utilisent des microprogrammes non libres aussi, ainsi que des bibliothèques non libres. À part cela, le code source des versions 1 et 2 d’Android telles que faites par Google sont libres, mais ce code est insuffisant pour faire tourner l’appareil. Quelques applications qui viennent généralement avec Android sont aussi non libres.

Android est très différent du système d’exploitation GNU/Linux, car il contient très peu de GNU. En effet, le seul élément commun entre Android et GNU/Linux se résume à peu près à Linux, le noyau. Les gens qui font l’erreur de croire que « Linux » fait référence à la totalité de l’écosystème GNU/Linux s’emmêlent les pinceaux, et font des affirmations paradoxales telles que « Android contient Linux, mais ce n’est pas Linux ». Si nous évitons cette confusion au départ, la situation est simple : Android contient Linux, mais pas GNU. Ainsi Android et GNU/Linux sont majoritairement différents.

À l’intérieur d’Android, le noyau Linux reste un programme séparé, avec le code source sous licence GNU GPL version 2. Combiner Linux avec le code sous licence Apache 2.0 représenterait une violation du copyright, puisque les licences GPL version 2.0 et Apache 2.0 sont incompatibles. Les rumeurs que Google a d’une manière ou d’une autre fait passer Linux sous licence Apache sont fausses. Google n’a aucun pouvoir pour changer la licence du code de Linux, et n’a pas essayé de le faire. Si les auteurs de Linux autorisaient son usage sous la version 3 de la licence GPL, ensuite ce code pourrait être combiné avec un code sous licence Apache, et la combinaison pourrait être rendue publique sous licence GPL version 3. Mais Linux n’a pas été publié ainsi.

Google a respecté les règles de la licence GPL (General Public License ou Licence publique générale) pour Linux, mais la licence Apache sur le reste d’Android n’oblige pas à montrer le code. Google a dit qu’ils n’allaient jamais publier le code d’Android 3.0 (à part Linux), même si les exécutables ont été rendus disponibles pour le public. Le code source d’Android 3.1 est aussi retenu. Ainsi, Android 3, en dehors de Linux, est purement et simplement du logiciel non libre.

Google a dit qu’ils gardaient le code source de la version 3.0 parce qu’il était bogué, et que les gens devraient attendre la version d’après. Cela pourrait être un bon conseil pour ceux qui veulent juste faire tourner le système Android, mais les utilisateurs devraient être ceux qui prennent ces décisions. Et de toutes façons les développeurs et les bidouilleurs qui voudraient inclure des changements dans leurs propres versions pourraient très bien utiliser ce code.

Le fait de ne pas rendre publique deux versions du code source est source d’inquiétudes dans le sens que Google pourrait vouloir rendre Android propriétaire de manière permanente, que la publication de quelques versions d’Android ait été une stratégie temporaire afin d’obtenir l’aide de la communauté pour améliorer un logiciel propriétaire. Espérons que ce n’est pas le cas.

Dans tous les cas, la plupart du code source de plusieurs versions d’Android ont été publiées en tant que logiciel libre. Est-ce que ça veut dire que des machines qui utilisent ces versions d’Android respectent les libertés de l’utilisateur ? Non, ce n’est pas le cas pour plusieurs raisons.

Tout d’abord, la majorité des versions comprend des applications non libres de Google pour communiquer avec des services tels que Youtube et Google Maps. Celles-ci ne font pas officiellement partie d’Android, mais cela n’en fait pas un bon produit pour autant. Il y a aussi la présence de bibliothèques non libres. Qu’elles fassent partie d’Android ou pas est discutable, ce qui importe c’est que beaucoup de fonctionnalités en dépendent.

Même les exécutables qui font officiellement partie d’Android peuvent ne pas correspondre au code des versions de Google. Les constructeurs peuvent changer le code, et bien souvent ils ne publient pas le code source de leurs versions. La licence GNU GPL les oblige, en théorie, à redistribuer le code de leurs versions de Linux. Le reste du code sous licence Apache ne les oblige pas à publier le code source des versions qu’ils utilisent réellement.

Replicant, une version libre d’Android qui n’est compatible qu’avec quelques modèles de téléphones, a remplacé beaucoup de bibliothèques, et peut fonctionner sans les applications non libres. Mais il y a d’autres problèmes.

Certains modèles sont conçus pour empêcher leur propriétaire d’installer et de modifier le logiciel. Dans cette situation, les exécutables ne sont pas libres, même s’ils sont faits à partir d’une source libre qui est disponible pour vous. Cependant, certains appareils Android peuvent être «?rootés?», ce qui permet aux utilisateurs d’y installer d’autres logiciels.

Les micrologiciels importants et les pilotes sont généralement propriétaires aussi. Ceux-ci gèrent le matériel pour le réseau, la radio, le wifi, le bluetooth, le GPS, l’accélération 3D, l’appareil photo, les hauts-parleurs, et dans certains cas le microphone aussi. Sur certains modèles, quelques-uns de ces pilotes sont libres, et pour certains on peut s’en passer, mais le microphone et l’accès au réseau sont plutôt indispensables.

Le micrologiciel qui gère l’accès au réseau est préinstallé. Si tout ce que le programme se contentait de faire était de tourner dans son coin, on pourrait le considèrer comme un simple circuit. Quand on insiste sur le fait qu’un logiciel dans un ordinateur doit être libre, on peut passer sur un micrologiciel préinstallé qui ne sera jamais mis à jour, car cela ne fait pas de différence pour l’utilisateur que c’est un programme plutôt qu’un circuit.

Malheureusement, dans ce cas ce serait un circuit malveillant. Des fonctions malveillantes sont inacceptables, quelle que soit la manière dont elles sont implémentées.

Sur la plupart des téléphones Android, ce micrologiciel a tellement de contrôle qu’il pourrait transformer le produit en un appareil d’écoute. Sur certains, il peut prendre le contrôle entier de l’ordinateur principal, à travers la mémoire partagée, et peut ainsi supplanter ou remplacer le logiciel libre que vous avez installé. Avec certains modèles, il est possible d’exercer un contrôle à distance sur ce micrologiciel, et ainsi sur le téléphone tout entier, à travers le logiciel permettant l’accès au réseau. Le principe du logiciel libre, c’est d’avoir le contrôle sur la machine, et cet appareil en l’occurence ne remplit pas cette mission. Bien que n’importe quel système informatique puisse avoir des bogues, ces appareils peuvent être des bogues (Craig Murray, dans Meurtre à Samarkand, fait le récit de son rôle dans une opération de renseignement qui convertit un téléphone portable sans Android d’une cible peu suspicieuse en un appareil d’écoute).

En tout cas, le micrologiciel du téléphone permettant l’accès au réseau n’est pas l’équivalent d’un circuit, car le matériel permet l’installation de nouvelles versions, et il fonctionne dans ce but d’ailleurs. Puisque c’est un micrologiciel propriétaire, en pratique seul le fabricant peut faire de nouvelles versions, les utilisateurs ne le peuvent pas.

Pour résumer, on peut tolérer des versions non libres des micrologiciels gérant l’accès au réseau à la condition que des mises à jour ne seront pas téléchargées, elles ne prendront ainsi pas contrôle de l’ordinateur principal, et il peut seulement communiquer quand et si le système d’exploitation libre le permet. En d’autres termes, il doit avoir un fonctionnement équivalent à un circuit, et ce circuit ne doit pas être malveillant. Il n’y a pas d’obstacles à construire un téléphone Android qui a ces caractéristiques, mais nous n’en connaissons aucun.

De récentes couvertures médiatiques se sont intéressées aux guerres de brevets. Pendant les 20 ans de campagne qui ont été consacrés à l’abolition des brevets logiciels, nous avons prévenu que de telles guerres pouvaient arriver. Les brevets logiciels pourraient contraindre à la disparition de fonctions dans Android, ou même le rendre indisponible (consultez endsoftpatents.org pour plus d’informations sur les raisons nécessitant l’abolition des brevets logiciels).

Pourtant, les attaques sur les brevets, et les réponses de Google, n’ont pas de lien direct avec le sujet de cet article : comment les produits Android sont proches d’un système de distribution éthique, et comment ils échouent de peu. Ce problème mérite l’attention de la presse aussi.

Android représente une étape majeure vers un téléphone portable libre qui soit contrôlé par l’utilisateur, mais il y a encore beaucoup de chemin à parcourir. Les hackers travaillent sur Replicant, mais c’est un gros travail de rendre un nouveau modèle compatible, et il reste encore le problème du micrologiciel. Même si les téléphones Android d’aujourd’hui sont considérablement moins mauvais que les smartphones d’Apple ou de Windows, on ne peut pas dire qu’ils respectent vos libertés.

La mise en ligne sur le Framablog de l’article Sortie du manuel « Introduction à la science informatique » a naturellement suscité des commentaires, bienvenus, variés et intéressants.

Quelques éléments pour poursuivre le débat entamé.

1) Quelle culture générale scolaire au 21è siècle ?

L’enseignement de spécialité optionnel « Informatique et Sciences du numérique » créé en Terminale S à la rentrée 2012 est un enseignement de culture générale. Comme il y en a d’autres au lycée : mathématiques, histoire-géographie, sciences physiques, philosophie… Il n’a pas vocation à former des spécialistes, cela étant il peut contribuer à susciter des vocations. Il correspond aux missions du système éducatif, à savoir former l’homme, le travailleur et le citoyen.

Les disciplines enseignées évoluent au fil du temps. On ne fait plus de géométrie descriptive en mathématiques mais des probabilités et des statistiques. Le latin et le grec n’ont plus la même place qu’au début du siècle dernier. Les sciences physiques sont devenues discipline scolaire car elles sous-tendaient les réalisations de la société industrielle. Or le monde devient numérique… L’informatique doit avoir sa place dans la culture générale scolaire car elle fait partie de la culture générale de notre époque. C’est un choix que la société fait, doit faire. Car il est clair que l’on ne peut pas tout étudier à l’Ecole. Il faut choisir le « midi qui a le plus de portes ».

Dans les commentaires, un argument nous a quelque peu surpris. Il ne faudrait pas d’informatique à l’École car « cela dégoûterait les élèves ». Le propos vaut-il pour la lecture ? N’apprenons pas à lire aux enfants. Comme cela ils ne seront pas dégoûtés et tous sauront lire. Pas sûr…

Il a été fait état, c’est inévitable, de la comparaison avec la conduite des automobiles. Rappelons que conduire une voiture, en fabriquer et étudier la thermodynamique sont trois activités de natures différentes. Comme l’utilisation des ordinateurs, leur fabrication et la science informatique le sont.

Tout le monde a en tête les débats vifs qui ont accompagné la transposition de la directive européenne DADVSI ou le vote de la loi Hadopi, et du sentiment que l’on a pu éprouver que beaucoup ne savaient pas de quoi ils parlaient. Quand les citoyens s’intéressent au nucléaire ils peuvent peu ou prou se référer à ce qu’ils ont appris à l’école en cours de sciences physiques (atome, courant électrique…). Quand ils s’intéressent aux OGM ils peuvent se référer à leurs cours de SVT. Le problème concernant l’informatique et le numérique est qu’il n’y a pas encore de cours d’informatique, scientifique et technique.

Enseigner une discipline informatique au lycée signifie fondamentalement être en phase avec la société telle qu’elle est devenue.

2) Pourquoi de la programmation ?

Faisons un détour par les mathématiques. Tous les élèves en font, de la Maternelle à la Terminale. Pourtant, bien peu seront chercheurs en mathématiques. Et tous ne seront pas ingénieurs ou professeurs de mathématiques. Ils apprennent à résoudre des équations, chose qu’ils ne feront plus le reste de leur vie. Ils étudient et construisent des fonctions. Pourquoi ? Parce qu’il est important de savoir qu’une grandeur peut dépendre d’une autre grandeur. Que, par exemple, la courbe du chômage indique une progression, éventuellement une accélération de cette progression. Pour s’approprier ces notions, il y a tout un long cheminement avec des appropriations de notions dont on ne se servira plus dans la vie. Mais il reste la culture, à savoir ce qui reste quand on a tout oublié !

Il en va de même pour la programmation. Elle est avec l’algorithmique, la théorie de l’information, l’architecture et les matériels l’un des quatre grands domaines de l’informatique, constituant une clé de voûte où les quatre arcs qui structurent l’informatique se rejoignent, A ce titre elle est déjà incontournable. Elle permet de comprendre ce qu’est l’informatique, de percevoir sa « nature profonde », de s’en imprégner. Pour s’approprier des notions (fichier, protocole de communication, « verrou mortel »…), rien de tel que d’écrire des « petits » programmes.

Cela vaut également pour l’apprentissage des autres disciplines. Encore faut-il que les élèves sachent programmer ! La programmation est un élément de cursus informatique apprécié des élèves, car elle les place dans une situation active et créative, dans laquelle ils peuvent eux-mêmes fabriquer un objet. On constate en effet avec l’ordinateur une transposition des comportements classiques que l’on observe dans le domaine de la fabrication des objets matériels. À la manière d’un artisan qui prolonge ses efforts tant que son ouvrage n’est pas effectivement terminé et qu’il fonctionne, un lycéen, qui par ailleurs se contentera d’avoir résolu neuf questions sur dix de son problème de mathématiques (ce qui n’est déjà pas si mal !), s’acharnera jusqu’à ce que « tourne » le programme de résolution de l’équation du second degré que son professeur lui a demandé d’écrire, pour qu’il cerne mieux les notions d’inconnue, de coefficient et de paramètre. Ces potentialités pédagogiques de la programmation, qui favorisent l’activité intellectuelle, sont parfois paradoxalement et curieusement oubliées par des pédagogues avertis (qui, par ailleurs apprécient les vertus de l’ordinateur et d’internet, outil pédagogique).

De plus, la programmation est une excellente école de la rigueur, de la logique. Vraiment, pourquoi s’en priver ?

3) Formation de culture générale et formations professionnalisantes

Si les disciplines scolaires sont générales et concernent tous les élèves, il n’empêche qu’elles contribuent à donner des fondamentaux que certains retrouveront dans leurs formations ultérieures et leur vie professionnelle. Toutes les disciplines sont des outils au service des autres, et aussi des fins en soi. Cela vaut par exemple pour les mathématiques qui sont au service des sciences physiques ou des sciences économiques. Et pour l’informatique bien sûr. Plus les disciplines sont au service des autres, plus elles deviennent une fin en elles-mêmes. Plus elles sont des composantes majeures de la culture des hommes. Informatique et littérature même combat. Écrire un programme ou écrire un texte sont deux activités d’égale dignité, tout aussi passionnantes l’une que l’autre : une fin en soi !

Une formation structurée sur une longue durée doit être organisée comme une fusée à deux étages : les premières années doivent être consacrées à l’apprentissage de savoirs fondamentaux, puis doivent venir les savoirs spécialisés, qui ont vocation à être directement utilisés dans (les premières années d’) une activité professionnelle. Par exemple la formation d’un médecin consiste à apprendre d’abord (dès l’école primaire, le collège et le lycée) des généralités sur l’anatomie et la physiologie humaine, avant d’apprendre tel ou tel geste chirurgical ou la posologie de tel ou tel médicament. Cette seconde phase de la formation est très variable en fonction du métier que l’on souhaite exercer : les mêmes savoirs spécialisés ne sont pas nécessaires à un ophtalmologiste et un anesthésiste, alors que l’un et l’autre doivent savoir que le cœur est à gauche et le foie à droite ou qu’une cellule humaine contient vingt-trois paires de chromosomes.

Avec l’arrivée de l’informatique au lycée se pose la question de l’identification des savoirs fondamentaux que l’on souhaite partager, non avec ses collègues, mais avec tous. Pour faire partie de la culture générale ces savoirs doivent :

• avoir une certaine stabilité,
• donner une image diversifiée, mais cohérente de la discipline,
• éclairer la vie quotidienne, mais aussi ouvrir de nouveaux horizons,
• permettre de comprendre comment utiliser des objets mais aussi comment ils sont conçus,
• être agréables et valorisants à apprendre.

Les besoins croissants en matière d’informatique et de numérique concernent des compétences diversifiées qui évoluent rapidement (outils, langages…), des métiers nouveaux avec peu de formations existantes (web 2,0, e-économie…). Cela signifie qu’il faut distinguer la formation pour tous aux fondamentaux de culture générale informatique, scientifique et technique, dans l’enseignement scolaire et dans l’enseignement supérieur, et les formations professionnalisantes qui, de par les évolutions incessantes des besoins, doivent justement pouvoir s’appuyer sur une solide formation initiale.

Jean-Pierre Archambault
Gilles Dowek

Voilà, on y est. Après la musique, c’est désormais la sphère du livre qui est pleinement impactée, voire bousculée, pour l’arrivée inopinée et intempestive du numérique.

Le second connaîtra-t-il les mêmes difficultés et résistances que le premier ?

On en prend le chemin… Sauf si l’on décide de s’inspirer fortement de la culture et des outils du logiciel libre.

Le samedi 24 septembre prochain, dans le cadre du BookCamp Paris 4e édition, Chloé Girard animera avec François Elie un atelier intitulé « Fabrication mutualisée d’outils libres pour les métiers de l’édition ».

Il s’agira de réflechir ensemble à comment « soutenir et coordonner l’action des professionnels du livre pour promouvoir, développer, mutualiser et maintenir un patrimoine commun de logiciels libres métiers » en développant notamment un forge dédiée destinée à « l’ensemble des acteurs de l’édition (éditeurs, distributeurs, diffuseurs, privés, publics, académiques…) »

L’expérience et l’expertise du duo sont complémentaires. François Elie, que les lecteurs du Framablog connaissent bien, sera en effet ici Monsieur Forge (en théorie dans son livre Économie du logiciel libre et en pratique depuis de nombreuses années au sein de la forge pour les collectivités territoriales ADULLACT). Chloé Girard, partenaire de Framasoft dans le cadre du projet Framabook, fera quant à elle office de Madame Métiers de l’édition.

C’est un entretien avec cette dernière que nous vous proposons ci-dessous.

C’est évidemment l’occasion de mieux connaître l’ambition et l’objectif de cette forge potentielle, en profitant de la tribune pour lancer un appel à compétences. Mais nous avons également eu envie d’en savoir davatange sur la situation générale et spécifique de l’édition d’aujourd’hui et de demain, sans taire les questions qui fâchent comme celle concernant par exemple Google Books 🙂

Remarque : Même si le site est encore en construction, nous vous signalons que les avancées du projet pourront être suivies sur EditionForge.org.

Edit : Finalement François Elie ne sera pas disponible pour l’atelier. Mais il reste bien entendu partie prenante du projet.

Une forge Métiers de l’édition – Entretien avec Chloé Girard

Chloé Girard bonjour, peux-tu te présenter succinctement à nos lecteurs ?

Je travaille depuis quatre ans avec David Dauvergne au développement d’un logiciel libre pour les éditeurs, La Poule ou l’Oeuf. C’est une chaîne éditoriale destinée à une édition mixte, papier et électronique.

Nous avons parallèlement créé une entreprise de service en informatique libre pour l’édition et travaillons avec plusieurs éditeurs et prestataires de services aux éditeurs pour de la production, parfois industrielle, de livres numériques. Nous travaillons également à la mise en place d’un processus interne de fabrication électronique lié au traditionnel processus papier.

Je suis également responsable de fabrication papier et électronique pour l’éditeur suisse d’érudition La Librairie Droz, et aborde le problème depuis le point de vue de l’éditeur, aspect financier compris.

Je suis donc au croisement entre l’édition associative, l’intégration et le service en logiciel libre métier et la fabrication de livres, papier et numérique chez un acteur traditionnel de la profession. Ces différentes expériences m’ont naturellement portées à me poser certaines questions qui sont à l’origine de mon intérêt pour cette notion de forge. Questions que nous ne sommes d’ailleurs pas les seuls à nous poser. Les différents BookCamp, salons du livre, commissions du CNL (Centre national du livre), associations professionnelles et éditeurs s’interrogent eux aussi sur les besoins, les outils, les limites, les possibles interactions, les manques, les évolutions, les formes, ou encore les formats dans la fabrication et l’exploitation des livres dans leur(s) version(s) numérique(s).

Comment vois-tu l’évolution actuelle du monde de l’édition, fortement impacté si ce n’est secoué, par les nouvelles technologies ?

Chez les petits éditeurs rien n’a changé. Les processus de fabrication sont toujours les mêmes, les livres sont conçus pour sortir en version papier, les processus de fabrication électronique, quand il y en a, sont externalisés et fortement subventionnés. Car peu d’éditeurs ont les ressources techniques, humaines et financières pour mettre au point de nouveaux mode de production en interne. Et leurs partenaires traditionnels n’en savent souvent pas plus qu’eux, d’autant que la question se pose encore de ce qu’il faut faire, de la pérénité des sources électroniques produites aujourd’hui, de ce qu’il faudra re-produire demain. Le marché s’amorce grace aux subventions à la production électronique. Elles se tariront forcément une fois le marché établi.

Pour autant il faudra bien le suivre ! Or les acteurs en bout de chaîne sont difficilement contrôlables. Par exemple les exigences de validité des fichiers ePUB par Apple sur le eBook Store changent régulièrement et renvoient des messages d’erreur que seuls des développeurs peuvent comprendre, et encore. Bref, beaucoup reste à faire. Une chose a changé au cours des trois dernières années c’est que les éditeurs ont compris qu’ils n’ont plus d’autre que d’y aller.

Je pense qu’il faut donner les moyens à tous les éditeurs de prendre les rênes de ces nouvelles technologies pour maintenir dans l’offre électronique une diversité de contenus et de formes que eux seuls, avec leurs auteurs, peuvent imaginer.

Une « forge Métiers de l’édition », mais quel est donc cet ambitieux nouveau projet ?

Une forge est une forme de département de recherche et développement (R&D) externalisé et, surtout, mutualisé. L’idée est de donner aux professionnels de l’édition les moyens de faire développer et évoluer ensemble les logiciels dont ils ont besoin pour leur métier.

Cela consiste en deux choses : d’une part réunir en un même lieu, atelier et magasin, les outils et compétences informatiques qui peuvent travailler ensemble, si nécessaire. Et, d’autre part, encadrer les éditeurs, imprimeurs, distributeurs, dans la rédaction des cahiers des charges de ces nouveaux outils (bureau d’étude).

Évidemment il est plus que souhaitable que ces outils soient libres, pour des questions d’interopérabilité, d’extensibilité, de transfert de compétences… mais aussi d’économies. Le code étant libre il est payé une fois pour son développement puis disponible pour tous. Disponible pour utilisation mais aussi pour le faire évoluer en fonction de nouveaux besoins, de nouveaux outils, de nouveaux support…

Tu évoques aussi « une place de marché entre clients métier, entrepreneurs et communauté du logiciel libre ». Peux-tu nous en dire plus et nous donner quelques exemples réels ou fictifs de situations où la forge est potentiellement un avantage ?

Les forges logicielles, horizontales, réunissent les acteurs du développement d’une application. Ici nous avons une forge cliente mise en place par les utilisateurs (professionnels de l’édition) qui y rencontrent les développeurs (représentés par les forges logicielles) aussi bien que les sociétés leur permettant de créer et de mettre en production ces outils. Les professionnels de l’édition peuvent donc lancer des appels d’offre auprès de prestataires qui peuvent y répondre ensemble ou séparément. Nous avons donc une réelle place de marché métier avec des clients et des vendeurs.

L’intérêt, par rapport à un système d’achat/vente classique de service informatique, c’est la mutualisation des expertises, du code et des services. Les éditeurs aujourd’hui rencontrent de nouveaux besoins, très techniques. Juger de la façon d’y répondre demande une expertise rare et coûte cher (voire très cher). Très peu d’éditeurs savent et peuvent assumer cela seuls et risquent d’y perdre beaucoup.

Imaginons qu’un éditeur convertisse aujourd’hui son catalogue d’ouvrages dans un format donné de livres électroniques. Que fera-t-il, ou plutôt comment fera-t-il si les supports de lecture de livre de demain, ebooks, tablettes ou PC, lisent un autre format que celui-là ou une version plus récente ? Nous sommes ici dans une situation parfaitement concrète et déjà réelle.

Sachant que la conversion d’un ouvrage papier en ePUB aujourd’hui coûte au minimum 1€ la page, qu’environ 60 000 ouvrages sont publiés par an en France et que le patrimoine à convertir regroupe des centaines de milliers d’ouvrages on peut imaginer les conséquences s’il faut re-produire ces fichiers.

Aujourd’hui cette conversion est largement subventionnée. Mais lorsque le marché du livre électronique sera suffisamment amorcé, ces subventions baisseront ou disparaîtront. Il faudra alors que les éditeurs assument seuls l’évolution de leur catalogue électronique. Et qu’ils en assurent l’évolution régulière. Une forge leur permettrait par exemple, si le format de départ est ouvert, de faire développer collectivement un outil de mise à jour automatisée du catalogue. Et de faire évoluer cet outil, avec une réactivité bien plus importante que s’il fallait attendre d’un éditeur de logiciel propriétaire qu’il décide lui-même de la sortie de la mise à jour nécessaire.

Les éditeurs y gagnent en matière d’autonomie, de réactivité sur leur marché et de capacité d’innovation. D’autant que les acteurs logiciels de la forge peuvent y déposer des « appels de demandes » c’est-à-dire des propositions d’innovation ou de développements auxquels les clients n’auraient pas forcément pensé. On a donc un lieu de propositions techniques en même temps que de marché, dans un cadre d’expertise partagée.

L’exemple simple d’évolutivité des formats est un problème que les éditeurs connaissent déjà bien ou qui les retient de se lancer dans l’édition numérique. Mais ils sont confrontés à bien d’autres problèmes : la réunion des processus papier et électronique (PDF imprimeur/ePUB, XML InDesign/XML divers…), l’exploitation des contenus en réseau (schémas de métadonnées, protocoles de communication entre catalogues et serveurs, schémas XML de description de contenus), le chiffrement des fichiers électroniques garantissant l’intégrité d’un document, l’enrichissement d’un ouvrage avec des contenus dynamiques ou multimédia, le lien livres et réseaux sociaux, l’offre de sorties s’adaptant à des écrans divers (graphisme), à des lecteurs divers (niveau de lecture, multilinguisme), sans perdre la notion de référence intellectuelle commune, les livres-applications, la gestion documentaire, les liens éditeurs/distributeurs/diffuseurs, la gestion des droits d’auteur, le lien entre l’exploitation du catalogue et les outils internes de gestion, de facturation, etc. Et encore, ces exemples ne sont qu’un petit apperçu des besoins et questions. Sachant que les réponses vont devoir évoluer au même rythme que les supports de lecture et les systèmes d’exploitation. Et que les problématiques ne sont pas les mêmes selon que l’on édite des romans, des thèses, des livres d’art, des manuels scolaires de la documentation technique ou des revues scientifiques.

Évidemment, chaque éditeur peut faire développer ses propres outils ou payer des licences pour chaque logiciel nécessaire. Mais gérer l’interopérabilité entre ces applications et un système un peu intégré deviendra impossible ou extrêmement onéreux. J’en suis témoin au quotidien. Les professionnels de l’édition ne pourront suivre l’évolution de leur métier, et la maîtriser, que collectivement.

Sauf s’ils décident de tout confier à Google Books !

Il faut considérer Google comme un prestataire comme les autres. Sauf que, étant donné la puissance du prestataire il vaut mieux être théoriquement et technologiquement averti et exigeant ! D’où la nécessité d’avoir ses propres outils pour ne pas être trop vulnérable.

En ce qui concerne leurs livres épuisés Google offre aux éditeurs une solution de facilité pour remettre sur le marché des livres qui n’y sont plus et n’y seront plus sans cela, étant donné le coût que cela représente. Pourquoi pas. La difficulté est alors de rester maître du cahier des charges et il vaut sans doute mieux posséder ses propres sources à négocier auprès de Google Books que de laisser Google convertir puis discuter des conditions.

Dans le passé beaucoup d’éditeurs ont confié la mise en page et l’impression de leurs ouvrages à des prestataires extérieurs, plus petits, plus locaux que Google, sans jamais réclamer en retour ni leurs fichiers natifs ni même les PDF imprimeurs ! Ils sont ainsi aujourd’hui dans certains cas obligés de racheter leurs propres fichiers à ces prestataires ou repartent du papier pour reconstituer leurs sources ! À eux de voir si ils veulent renouveler l’expérience.

Avoir des outils disponibles pour produire leurs sources efficacement et les faire évoluer, leur permettrait de négocier différemment avec Google aujourd’hui mais aussi demain. Parce que demain Google va offrir de nouveaux services sur ces sources. S’il est encore le seul à pouvoir, techniquement, les offrir, il sera à nouveau en position de force. Or ces épuisés constitueront sans doute une part non négligeable des ventes. Il vaut donc mieux se préparer à récupérer ces sources et à les exploiter intelligemment soi-même. Face aux équipes de développement de Google un éditeur seul, ou n’importe lequel de ses prestataires en édition numérique, à intérêt à avoir de sacrés moyens pour offrir des solutions concurrentes.

Pour les publications récentes et nouvelles la question se pose différemment. La question n’est pas seulement de mettre en ligne, de mettre à disposition pour achat, mais bien aussi de créer des versions numériques qui apportent quelque chose de plus par rapport au papier : pour le lecteur, pour l’exploitation des savoirs, pour la conservation du patrimoine. C’est un acte éditorial, ce n’est donc pas Google qui peut s’en charger.

Après, si Google offre des solutions libres assurant l’interopérabilité avec les outils internes de fabrication et de gestion des éditeurs, distributeurs, imprimeurs, etc. Si Google produit des sources ouvertes que les éditeurs peuvent récupérer, retirer, si l’on peut interfacer des outils libres de gestion de droits avec Google Books, si… alors bienvenue à Google au sein de la forge « métiers de l’édition » ! À voir…

Face à Google comme face à n’importe quel prestataire et plateforme d’exploitation il faut que les éditeurs travaillent ensemble, et avec leurs distributeurs, diffuseurs, etc, à des solutions qui leurs permettent de maîtriser leurs oeuvres et leur métier.

Après Google, en quoi cette forge se distingue-t-elle des API censés « ouvrir le contenu aux développeurs » telles que proposées par Amazon ou tout récemment par Pearson ?

L’initiative de Pearson est géniale ! « L’idée est de regarder si la créativité des développeurs permet d’amener l’exploitation de ces contenus dans des directions que les éditeurs n’avaient pas explorées jusqu’alors ». Mais ce qui est intéressant dans l’article de Guillaud c’est aussi sa dernière phrase : « Assurément, Pearson lance un mouvement que les plus gros ne devraient pas tarder de prolonger… »

Que vont faire les petits et moyens éditeurs pendant ce temps-là ? Et les diffuseurs, les libraires ? Je crois que la forge, la mutualisation, un patrimoine d’outils communs, leur permettront justement d’accéder à ce type de moyens d’exploitation, de plateformes éditoriales ouvertes aux codeurs, aux innovations. Demandez aux éditeurs, au hasard, si ils savent ce qu’est une API ! Il faut une sacrée expertise pour mettre en oeuvre ce type d’accès et les faire évoluer, sur les plans technique mais aussi juridique d’ailleurs. Même les gros éditeurs ont besoin, pour la plupart, de mutualiser, au moins en partie, les frais de R&D pour développer et innover dans de tels services. Or c’est ce que tous cherchent à faire. Mais je ne suis pas sûre que Pearson va leur donner ses trucs demain !

Est-ce une application directe et concrète des propositions de François Elie dans son livre Économie du logiciel libre ?

Oui, absolument. Et François Élie nous accompagne dans la réflexion et la présentation du projet, fort de son expérience de l’Adullact (Association des Développeurs et des Utilisateurs de Logiciels Libres pour l’Administration et les Collectivités Territoriales) et de son verbe coloré. La killer application openCimetiere fait toujours son petit effet !

« On ne peut utiliser que des logiciels qui existent » et « un logiciel libre est gratuit une fois qu’il a été payé ». Ces deux phrases extraites de son livre résument bien l’intérêt que peuvent trouver clients et développeurs libres au sein d’une telle forge : 1) coté client : maîtriser ses outils métier, gagner en réactivité, faire, éventuellement, des économies 2) coté développeurs : financer en amont le développement libre, intégrer une place de marché active réunissant des compétences multiples pour ne pas réinventer la roue.

Quels sont les principaux freins que vous risquez de rencontrer et qu’il faudra dépasser d’après toi ? Le poids des habitudes ? L’absence d’une réelle culture de la mutualisation ? La concurrence non libre ?

La forge Adullact, comme son nom l’indique, s’adresse à des clients et des fonds publics. L’idée de dépenser des fonds publics une seule fois pour tous est (semble !) naturelle. Dans le cas d’une forge métiers de l’édition nous nous adressons en grande partie à des acteurs privés. Et le premier frein que nous avons rencontré est bien celui de la mutalisation des fonds : « pourquoi est-ce que je paierais pour des logiciels dont tous bénéficieront, y compris ceux qui n’auraient pas participé ? » Le problème n’est pas seulement celui du partage mais de la perte d’un avantage concurenciel.

En ce qui concerne le partage ce n’est pas très difficile à argumenter : ceux qui en profiteront ne tarderont pas à participer, à hauteur de leurs moyens et de leurs besoins. D’autre part plus un logiciel sera utilisé plus il sera pérenne.

Pour la question de la concurrence c’est plus délicat puisque le service autour des livres électroniques devient un enjeu économique. Il ne s’agit plus seulement de vendre des exemplaires mais aussi des services sur les contenus. Or les outils de fabrication ont un impact sur les possibilités de services commerciaux en aval. Imaginons par exemple un outil offrant de fabriquer des livres avec plusieurs niveaux de contenus auxquels les lecteurs auraient accès ou non selon qu’ils sont acheteur unique, abonnés ou abonnés premium.

Mais les éditeurs sont libres de faire développer certains outils, qui leurs semblent moins concurrenciels dans cette logique de mutualisation, et de faire développer chacun pour soi des extensions ou des modules d’exploitation qui leurs seraient propres. Une forge n’implique pas d’y faire produire tous ses projets. Quitte à se rendre compte finalement qu’il est plus intéressant de les y verser pour les faire maintenir et évoluer collectivement.

Cette logique de mutualisation dans une économie privée et auprès d’acteurs dont les finances sont souvent fragiles n’est pas gagné. Pourtant nous travaillons avec plusieurs éditeurs qui en rêvent. Ils n’ont ni les compétences ni les moyens de faire développer seuls les outils qu’il leur faut et que personne ne leur propose aujourd’hui.

Un autre obstacle est l’absence de culture du logiciel libre dans l’édition : elle était celle que l’on peut imaginer dans un milieu très peu technophile et surtout préoccupé de ne pas avoir à mettre les mains dans le cambouis, l’image du logiciel libre étant celle de la ligne de code dans un terminal. D’autant que les besoins étaient en (très) gros jusqu’ici celui d’un seul outil, de mise en page, propriétaire, cher, produisant un PDF, unique besoin des imprimeurs.

Depuis quelques années la notion de format ouvert fait cependant son chemin, notamment avec le format ePUB et le XML. Mais on est encore dans la logique du bon format, plutôt que dans celle du format ouvert.

J’ai quand même entendu il y a un an et demi un responsable de l’édition électronique chez un éditeur important affirmer qu’il n’utiliserait plus en fabrication que des logiciels libres. Pour des questions de pérénité et de maîtrise de son catalogue.

Mais pour répondre à cela il faut des acteurs et des outils libres qui répondent aux besoins de marchés importants, de volumes importants et d’éditeurs pressés. Il faut des partenaires libres solides, aisément identifiables, dans un écosystème libre métier qui permet de répondre rapidement aux évolutions des besoins.

C’est ce à quoi nous appelons aujourd’hui. Nous devons présenter dès l’origine de cette forge les acteurs du logiciel libre, éditeurs de logiciels, communautés, intégrateurs, pertinents, compétents et innovants pour répondre aux besoins de ces métiers. Nous connaissons un certains nombre de ces ressources et acteurs, mais pas tous. D’autant que certaines des compétences dont ont besoin les éditeurs aujourd’hui étaient jusque-là exploitées dans d’autres domaines métiers, telles que la gestion documentaire.

Nous avons besoin de constituer un catalogue de ressources libres à présenter aux éditeurs pour amorcer cette forge.

Ensuite se posera la question de sa gouvernance puisque, comme pour l’Adullact, la forge est un outil monté par les clients pour les clients, donc par les éditeurs pour les éditeurs. Je pense qu’une association professionnelle métier devrait prendre en charge ce projet comme une forme de nouveau service offert à ces membres.

Deux réunions sont prévues pour envisager concrêtement les actions à mettre en oeuvre pour que cette forge soit effective : le 24 septembre au BookCamp Paris 4 qui se tiendra au Labo de l’Édition (atelier 13) et début octobre dans une réunion organisée par le MOTif, organisme de politique du livre de la Région Île de France.

En visite en Angleterre, voici ce que disait le patron de Google dans une récente traduction du Framablog : « Je suis sidéré d’apprendre qu’il n’existe même pas d’enseignement de base de l’informatique dans les écoles britanniques aujourd’hui. Votre programme de technologie se concentre sur la manière d’utiliser un logiciel, mais n’explique pas comment il a été conçu. »

Et Slate.fr d’en remettre une couche le 4 septembre dernier dans son pertinent article La programmation pour les enfants: et pourquoi pas le code en LV3 ? : « Lassés d’avoir bouffé des slides de PowerPoint et des tableurs Excel dans leurs jeunes années, les étudiants se sont détournés peu à peu de l’étude de l’informatique confondant, bien malgré eux, l’apprentissage d’applications qu’ils trouvent généralement inintéressantes et celui des sciences computationnelles dont ils ne comprennent même pas l’intitulé. »

Toujours dans le même article : « On fait beaucoup d’esbroufe sur la délocalisation d’activités telles que la création de logiciel, mais ce qui n’est pas clair dans cette histoire c’est où est la charrue et où sont les bœufs. Est-ce que les entreprises délocalisent par ce que cela leur coûte moins cher et dans ce cas nous perdons des emplois sur le territoire, ou bien le font-elles parce qu’elle ne peuvent tout simplement pas recruter ici si bien qu’elles à se mettent rechercher des gens compétents ailleurs ? ».

Owni, quant à lui, va encore plus loin, avec son appel à hacker l’école accompagné du témoignage d’un père qui souhaite que sa fille en soit.

Lentement mais sûrement on prend enfin conscience que l’enseignement de l’informatique est un enjeu fondamental du monde d’aujourd’hui. Il y a ceux qui maîtriseront, ou tout du moins comprendront, le code et il y a ceux qui utiliseront le code créé par d’autres.

C’est pourquoi l’arrivée en France pour la rentrée 2012 en Terminale S de l’enseignement de spécialité « Informatique et sciences du numérique » est une avancée importante que l’on doit saluer comme il se doit.

Tout comme nous saluons ci-dessous la sortie d’un manuel support de cette nouvelle discipline (mais qui pourra également être utile et précieux à tout public intéressé par le sujet). Sous licence Creative Commons il a été rédigé collectivement par certains de ceux qui se sont battus avec force, courage et diplomatie pour que cet enseignement voit le jour (à commencer par Jean-Pierre Archambault que les lecteurs de ce blog connaissent bien).

Peut-être penserez-vous que c’est dommage et pas assez ambitieux de se contenter d’une spécialité pour la seule classe tardive de Terminale S ? (Peut-être jugerez-vous également que la licence Creative Commons choisie par le manuel n’est pas « assez ouverte » ?) Certes oui, mais en l’occurrence nous partons de si loin que l’on ne peut que se réjouir de ce petit pas qui met le pied dans la porte.

Et le Libre dans tout ça ?

Point n’est besoin de consulter les communiqués dédiés de l’April et de l’Aful, mentionnés ci-dessous, pour comprendre qu’il devrait largement bénéficier lui aussi de l’apparition de ce nouvel enseignement, synonyme de progrès et d’évolution des mentalités à l’Education nationale.

Edit du 18 septembre : Il y a une suite à cet article puisque les auteurs, Gilles Dowek et Jean-Pierre Archambault, ont choisi de commenter les nombreux et intéressants commentaires dans un nouveau billet.

Un manuel Introduction à la science informatique

Un manuel Introduction à la science informatique est paru en juillet 2011, destiné aux professeurs qui souhaitent se former avant de dispenser l’enseignement de spécialité « Informatique et sciences du numérique », créé en Terminale S à la rentrée 2012^[1]. Il s’adresse aussi potentiellement à d’autres publics souhaitant s’approprier les bases de la science informatique^[2].

Edité par le CRDP de Paris^[3], ce manuel a été écrit par 17 auteurs^[4] et coordonné par Gilles Dowek, directeur de recherche à l’INRIA. La préface est de Gérard Berry, professeur au Collège de France et membre de l’Académie des Sciences. Ce livre est sous licence Creative Commons : paternité, pas d’utilisation commerciale, pas de modification.

Il est composé de 7 chapitres : Représentation numérique de l’information ; Langages et programmation ; Algorithmique ; Architecture ; Réseaux ; Structuration et contrôle de l’information ; Bases de données relationnelles et Web. Les chapitres comportent une partie de cours présentant les concepts, d’exercices corrigés et non corrigés, d’une rubrique consacrée aux questions d’enseignement, et de compléments permettant d’aller plus loin, en particulier d’aborder quelques questions de société en liens avec la révolution informatique.

Le programme des élèves de Terminale S

Ce contenu reprend, sous une forme plus approfondie, les éléments du programme de la spécialité « Informatique et Sciences du numérique » proposée à la rentrée 2012 aux élèves de Terminale S et qui est construit autour des quatre notions fondamentales d’information, d’algorithme, de langage et de machine), notionss qui structurent les grands domaines de la science informatique.

• Représentation de l’information
  • Représentation binaire, opérations booléennes, numérisation, compression, structuration et organisation de l’information.
  • Ancrées dans les notions étudiées, des questions sociétales seront abordées : persistance de l’information, non-rivalité de l’information, introduction aux notions de propriété intellectuelle, licences logicielles.
• Algorithmique
  • Des algorithmes simples (rechercher un élément dans un tableau trié par une méthode dichotomique) et plus avancés (recherche d’un chemin dans un graphe par un parcours en profondeur) seront présentés.
• Langages de programmation
  • Types de données, fonctions, correction d’un programme, langages de description (présentation du langage HTML).
• Architectures matérielles
  • Architectures des ordinateurs : éléments d’architectures, présentation des composants de base (unité centrale, mémoires, périphériques.), jeu d’instructions.
  • Réseaux : transmission série – point à point – (présentation des principes, introduction de la notion de protocole), adressage sur un réseau, routage.
  • La question de la supranationalité des réseaux sera abordée.
  • Initiation à la robotique

Quid du libre ?

La liberté des usagers de l’informatique, le contrôle des outils qu’ils utilisent supposent qu’ils comprennent et maîtrisent les concepts qui les sous-tendent. Un système d’exploitation, un traitement de texte ou un tableur sont des outils conceptuels compliqués et complexes de par les objets qu’ils traitent et la multitude de leurs fonctionnalités. Le libre, c’est-à-dire le code source que l’on connaît et non pas une approche en termes de « boîte noire » miraculeuse qui fait tout pour vous (curieuse d’ailleurs cette représentation mentale qu’ont certains de la prothèse du cerveau qu’est l’ordinateur, que l’on pourrait utiliser sans la connaître ni la comprendre), s’inscrit pleinement dans la vision qui considère que l’homme, le travailleur et le citoyen doivent avoir une culture générale informatique scientifique et technique.

C’est donc très naturellement que l’APRIL s’est félicité de la création de l’enseignement « Informatique et Sciences du numérique ». Le 5 janvier 2010, dans un communiqué de presse, rappelant qu‘« elle a toujours été favorable à ce que l’informatique soit une composante à part entière de la culture générale scolaire de tous les élèves sous la forme notamment d’un enseignement d’une discipline scientifique et technique », elle soulignait « cette première et importante avancée signe d’une certaine rupture ». Elle mentionnait que « l’expérience de ces dernières années a clairement montré que le B2i ne fonctionnait pas. Son échec prévisible tient notamment à des problèmes insolubles d’organisation, de coordination et de cohérence des contributions supposées et spontanées des disciplines enseignées. De plus ne sont pas explicitées les connaissances scientifiques et techniques correspondant aux compétences visées ».

D’une manière analogue, dans un communiqué le 23 mars 2010, l’AFUL faisait des propositions pour l’Ecole à l’ère numérique parmi lesquelles : « L’informatique devient une discipline à part entière, dont l’enseignement obligatoire dès le primaire est réalisé par des professeurs ayant le diplôme requis dans cette spécialité ou ayant bénéficié d’une formation qualifiante. La gestion des compétences, l’accompagnement des enseignants et la formation initiale et continue font l’objet du plus grand soin. ».

Gilles Dowek et Jean-Pierre Archambault

Remarque : En réponse aux commentaires ci-dessous, les auteurs ont choisi publié un nouvel article qui précise et complète un certains nombres de points évoqués ici.

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

Pour un débutant participer au logiciel libre peut être si intimidant qu’on n’hésite pas à évoquer « un aquarium à requins » pour qualifier la communauté !

Un blogueur explique pourquoi il ne contribue pas au logiciel libre (alors qu’au fond de lui il le souhaite sincèrement). Un autre lui répond, en théorie mais aussi en pratique en s’appuyant sur GitHub (qui a le vent en poupe actuellement chez les développeurs). Telle est la petite passe d’armes que nous vous proposons traduite ci-dessous^[1].

En ce qui nous concerne, c’est aussi pour cela que l’on a publié notre framabook Produire du logiciel libre. Afin de participer à ce qu’il y ait de plus en plus de développeurs francophones, notamment parmi les plus jeunes qui ne reçoivent pour le moment aucune sensibilisation ou formation pendant leur cursus scolaire.

Pourquoi je ne contribue toujours pas à l’open source

Why I still don’t contribute to open source

The Daily Flux – 3 mai 2011 – Brandonhays.com
(Traduction Framalang : Pandark)

Je suis tellement hypocrite. Il y a quelques mois, je me demandais dans un billet comment surmonter ma peur de contribuer aux logiciels open source ?¹?.

Depuis, je n’ai toujours pas vraiment participé. Sur Twitter, j’ai écrit que les FOSS ressemblent à un aquarium de requins pour les newbies, et il faut que je le confirme.

Le fait est que je contribue activement d’une manière ou d’une autre à plusieurs projets open source. Cependant, je me sens toujours extérieur au projet, car mes contributions ne sont généralement pas liées au code. Alors pourquoi est-que je ne m’implique pas complètement dans le FOSS (et je pense, beaucoup d’autres comme moi) ?

Au risque de prêter aux autres mon ressenti personnel, j’aimerais vous faire part des obstacles qui peuvent, selon moi, intimider les nouveaux devs qui voudraient contribuer à des logiciels open source.

Il n’y a pas de certification, de cérémonie ou de badge du mérite disant « Tu es prêt à contribuer au FOSS ». (Il y en a cependant un pour après)

Il n’est pas évident de savoir par où commencer. D’après ce que j’entends, beaucoup de contributions aux FOSS surviennent parce que quelqu’un a besoin d’une fonctionnalité qui n’existe pas dans un logiciel, ou trouve un bug. Il peut proposer une procédure de test reproductible, voire un patch. Dans mon utilisation quotidienne, je ne croise pas beaucoup de ces situations. Il n’y a pas beaucoup de devs qui agitent les bras en demandant spécifiquement de l’aide sur un projet, et encore moins qui voudraient prendre un nouveau développeur sous leur aile.

Les règles de participation (guidelines) rendent souvent la vie d’un mainteneur plus facile, et compliquent la mienne. Oui, maintenir un projet open source est une tâche ardue et ingrate. Cependant, j’ai vu des règles/lignes de conduite pour contribuer qui transformaient une simple idée de correction en un mur de brique bureaucratique digne de Microsoft. La page d’accueil aux contributions accompagnée d’un tutoriel vidéo de Wayne Seguin est une exception remarquable à cela.

L’open source est pour les gens qui sont meilleurs que moi. J’ai bien conscience que c’est une excuse pour ne pas me lancer, mais je ne suis simplement pas à l’aise de me retrouver à un endroit où je pourrais publier des logiciels suffisamment bons pour que de véritables développeurs les utilisent.

Essayer de contribuer et échouer me donne le sentiment d’être stupide. J’ai déjà soumis plusieurs requêtes de pull et aucune n’a été acceptée, sans commentaire expliquant pourquoi. C’est comme si l’univers confirmait que oui, je suis un idiot, et mon « aide » n’est pas utile. Quelle perte de temps profondément déprimante !

J’ai pas le temps. J’ai des enfants, un nouveau boulot, et un nombre grandissant de responsabilités. Cela me prend entre 3 et 10 fois plus de temps pour écrire du code qu’un développeur plus expérimenté. Maintenant, mes contributions non liées au code mangent le temps que je passais à coder. Oui, tout le monde a la même excuse, du genre qui se dissipe si les autres excuses disparaissent, mais ça vaut le coup de le mentionner.

C’est une activité solitaire. Je pense que la plupart des gens comprennent ces choses par eux-même, et que ce serait donc un peu trop demander que d’attendre d’être pris par la main. Mais est-ce vraiment une démarche spirituelle où personne ne peut vous accompagner, de crainte que vous n’appreniez rien ?

Donc oui, le FOSS peut sembler intimidant, voire autant qu’un aquarium de requins. Je n’ai pas toutes les réponses à ces problèmes, mais je voudrais voir plus de mainteneurs cherchant des contributions avec une certaine spécificité, et répondant ensuite aux requêtes de pull, un appel pour des cas de tests supplémentaires, des corrections de bugs et, oui, de la documentation.

Github a beau être on ne peut plus ouvert, il n’y a pas de système type Quora/StackExchange qui permette de savoir quel projets ont besoin de quelque chose qui correspond à ce que vous pouvez faire. Ça pourrait être une bonne fonctionnalité.

Toi (oui, toi !), tu devrais contribuer à l’open source

You (yes, you!) should contribute to open source

Steve Klabnik – 10 mai 2011 – TheChangelog.com
(Traduction Framalang : Pandark)

Si vous lisez ce blog, vous vous souciez évidemment de l’open source. Si vous n’avez jamais contribué à un projet open source, cependant, vous êtes peut-être frileux à ce propos. Donc, inspiré par le concours de documentation Ruby 1.9.3, j’ai écrit un billet pour mon blog à propos de la manière de contribuer à la documentation de Ruby. J’ai reçu des retours comme celui-ci :

@steveklabnik Hé, c’est génial. Il est temps pour moi de m’engager et de me mettre au boulot. Merci pour la motivation supplémentaire !

Je me suis donc dit que quelque chose de plus général pourrait vous encourager à vous impliquer dans n’importe lequel des projets open source que vous utilisez, même si ce n’est pas en Ruby. Tout projet peut avoir besoin d’un coup de main supplémentaire, en particulier les petits.

Un petit aparté à propos du fait d’être frileux.

Si vous ne contribuez pas parce que vous pensez que vous n’êtes pas prêt, ne vous inquiétez pas pour ça ! Je sais que c’est plus facile à dire qu’à faire, mais vraiment, vous êtes prêt. Un de mes amis a publié un article à propos des raisons pour lesquelles il ne contribue pas, et je suis sûr que beaucoup de personnes partagent ce genre de peurs. Greg Brown a répondu et a dissipé certaines de ses inquiétudes, mais la plupart des gens auxquels j’ai parlé s’y refusent principalement pour deux raisons :

• C’est trop dur
• Je ne suis pas assez bon pour contribuer
• Je n’ai pas le temps

Parlons de chacun de ces points dans l’ordre inverse. C’est vrai, vous pouvez avoir une vie remplie. Je ne connais pas votre emploi du temps personnel. Cependant, je suis sûr que vous pouvez trouver une heure ou deux, peut-être un week-end ? Il n’en faut pas plus pour commencer. La plupart des projets sont construits sur la base de milliers de minuscules commits. Vous n’avez pas besoin de faire une grosse contribution, même les petites sont importantes.

Si vous avez peur que la qualité de votre code ne soit pas suffisante, eh bien la seule manière de vous améliorer est de pratiquer. Alors lancez-moi cet éditeur et soumettez un patch ! En général, si quelque chose ne va pas dans votre soumission, il y aura une discussion à son propos sur GitHub et tout le monde peut y apprendre quelque chose.

Prenez cette demande de pull, par exemple. À l’origine, Colin a soumis un patch qui faisait un lien vers la mauvaise url ; wilkie l’a mentionné, et Colin a mis le code à jour. Cela sera intégré dès que j’aurai fini d’écrire ce billet pour The Changelog. 🙂 Mais c’est généralement ce qui arrive si votre première proposition est un peu inexacte. N’ayez pas peur ! C’est comme ça que l’on a tous appris, les uns des autres.

Cette lamentation « c’est trop dur » débouche souvent sur un « je ne suis pas assez bon ». Cela peut aussi arriver si vous essayez de contribuer à un gros projet ayant beaucoup de règles. Les lignes de conduite pour contribuer, obligation de relecture du code, mise à jour des fichiers AUTHORS et CHANGELOG… les gros projets doivent avoir des procédures pour gérer le grand nombre de contributeurs, mais cela peut certainement créer une barrière à l’entrée pour les nouveaux venus. Si ces procédures vous intimident, j’ai une suggestion : commencez petit ! Les petits projets ont généralement peu, voire pas du tout de procédure. De plus, vous vous sentirez incroyablement bien. Pensez à ça : Python reçoit un tas de patchs tous les jours, mais si vous avez un petit outil que vous avez écrit sur GitHub, et que soudainement vous recevez un courriel « Hé, quelqu’un a un patch pour vous, » je parie que vous en serez rudement content.

Le B.A BA

Lorsque l’on contribue à un projet open source sur GitHub, il y a un processus que presque tous les projets suivent. Trois étapes : fork, commit, demande de pull.

GitHub rend l’étape du fork très simple. Cliquez simplement sur le bouton « fork » trouvé sur la page de n’importe quel projet. Utilisons Ruby comme exemple. La page du projet est ici. Vous pouvez voir le bouton fork en haut à droite. Il ressemble à ceci :

Cliquez dessus, et vous verrez certaines « hardcore forking action, » puis vous serez dans votre propre fork ! C’est votre propre version du projet, et elle apparait sur votre page GitHub. Par exemple, voici mon fork de Ruby. Vous verrez une URL sur la page, qui vous permettra de cloner ce projet lui-même.

$ git clone git@github.com:steveklabnik/ruby.git

Cela crée un répertoire « ruby » avec tout le code à l’intérieur. Ensuite, ajouter un lien vers le projet parent pour pouvoir suivre les modifications qu’il fait.

$ cd ruby
$ git remote add upstream https://github.com/ruby/ruby.git
$ git fetch upstream

À partir de maintenant, à n’importe quel moment, nous pouvons récupérer les modifications du dépôt Ruby principal en faisant un rebase :

$ git rebase upstream/master

Une petite remarque : ruby continue d’utiliser à la fois svn subversion et git, ils appellent donc leur branche maîtresse trunk. Si vous faites cela pour Ruby, vous devrez faire git rebase upstream/trunk. Maintenant que vous avez cloné, vous pouvez faire votre boulot ! J’aime travailler dans des branches par fonctionnalités, parce que cela rend les choses plus propres et jolies, et que je peux travailler sur deux fonctionnalités à la fois.

$ git checkout -b feature/super-cool-feature
$ vim something
$ git add something
$ git commit -m "Fixed something in something"

Une fois que vous avez obtenu des commits qui fixent votre problème, envoyez les (faites un push) sur GitHub :

$ git push origin feature/super-cool-feature

Ensuite, vous cliquez sur le bouton pull request :

Choisissez votre branche, modifiez la description comme vous le souhaitez, et vous êtes prêt à vous lancer ! Le mainteneur du projet y jettera un coup d’œil et vous aurez peut-être droit à une discussion, et bientôt vous aurez quelque chose accepté quelque part !

À quoi devrais-je contribuer ?

Le meilleur moyen de contribuer est d’aider un projet que vous utilisez effectivement. De cette manière, vous arriverez à tirer profit du fruit de votre labeur. Vous serez plus motivé, vous comprendrez déjà le projet et ce qu’il fait, ce qui vous rendra tout ça plus facile.

Si vous ne voulez pas ou ne pouvez pas trouver comment fonctionne quelque chose que vous utilisez, le deuxième meilleur moyen est de commencer à utiliser de nouveaux logiciels ! Continuez à lire The Changelog et choisissez un projet qui a l’air intéressant, utilisez le quelques semaines, puis contribuez !

Nous sommes tous dans le même bateau

J’espère que ceci vous encouragera à vous salir les mains, vous retrousser les manches, et contribuer. Même le plus petit des patchs est important, alors s’il vous plaît, trouvez un moment dans votre emploi du temps, choisissez un projet et faites un essai. Mais attention, vous pourriez vite vous retrouver accro !

Du projet One Laptop per Child (ou OLPC) les grands médias ont surtout retenu qu’il s’agissait de mettre un ordinateur entre les mains des enfants des pays défavorisés. Confondant la fin et les moyens ils sont alors souvent passés totalement à côté de son intérêt principal qui est pédagogique. Negroponte n’a de cesse à juste titre de le répéter : « le projet OLPC n’est pas un projet informatique, c’est un projet éducatif ».

Lorsqu’une écolière Uruguayenne et un écolier Uruguayen allument leur petit ordinateur vert, ils se retrouvent sur une interface qui est fort différente du classique environnement graphique d’un Mac, Windows ou d’une distribution GNU/Linux.

Ici on abandonne la métaphore du bureau. Applications et fichiers sont bien entendu toujours présents mais ce qui est mis en avant c’est l’interaction avec les autres, ce qui apparaîtra de suite à l’écran c’est la présence du camarade, ce sur quoi il travaille, sachant qu’il est alors facile de le rejoindre pour collaborer.

Cette interface innovante et pleine de promesses s’appelle Sugar (cf vidéo). Elle est déjà massivement utilisée dans des pays comme l’Uruguay (cf vidéo) et nous voici alors projetés à des années-lumière de ce qu’une école française peut proposer non seulement comme outil mais aussi et surtout comme conception générale de sa fonction et de ses missions^[1].

En matière d’éducation et de nouvelles technologies, il y a ceux qui pensent qu’il est important de savoir comment mettre en gras dans Word, c’est-à-dire apprendre le mode d’emploi d’un logiciel propriétaire, et il y a ceux qui veulent en profiter pour… changer le monde !

Le créateur de Sugar, Walter Bender, est de ceux-là. Simon Descarpentries l’a rencontré pour nous à Paris à l’occasion de l’Open World Forum 2010 et il a gentiment accepté de nous livrer un texte inédit nous présentant la jeune fondation Sugar Labs, sa philosophie, ses objectifs et ses réalisations.

Il ne s’agit que d’un témoignage mais c’est un témoignage important car il est bien possible que se trouve là l’une des pistes possibles et souhaitables pour l’éducation de demain. Et il n’est guère étonnant de constater la convergence entre une conception dynamique, créative et collective de l’apprentissage et le logiciel libre et sa culture.

Culture communautaire : l’expérience Sugar Labs

Community culture: The experience of Sugar Labs

Walter Bender – décembre 2010 – Licence Creative Commons By-Sa
(Traduction Framalang : Siltaar, Goofy, Seb seb, Zitor, Julien et Barbidule)

Dans un article publié il y a 30 ans et intitulé « Critique de l’ordinateur contre pensée technocentrique », Seymour Papert écrivait : « le contexte du développement de l’homme est toujours la culture, jamais une technologie isolée ». Dans un autre passage du même article, Papert offre un aperçu de ce qui est nécessaire pour fonder une culture de l’apprentissage : « Si vous vous demandez que doit savoir un pratiquant averti du LOGO, la réponse va au-delà de la capacité à utiliser et enseigner le LOGO. L’adepte doit être capable de parler du LOGO, d’en faire la critique, et de discuter des critiques émises par d’autres personnes ».

30 ans après, remplaçons « LOGO » par « Sugar »

Sugar est une plateforme logicielle destinée à l’éducation des enfants. Sugar est développé et maintenu par Sugar Labs, une communauté mondiale de développeurs et d’éducateurs bénévoles. Notre objectif est l’émergence d’une génération de penseurs critiques et de gens capables d’inventer des solutions. À travers Sugar, nous nous efforçons de procurer à chaque enfant une chance d’apprendre et d’apprendre à apprendre, dans un contexte qui va lui permettre à la fois d’entamer un échange dynamique avec d’autres et de développer des moyens indépendants pour atteindre ses objectifs personnels.

Que devraient apprendre les enfants et comment devraient-ils apprendre ? Ceux qui apprennent devraient avoir accès aux idées qui nourrissent leur culture locale de même qu’aux idées puissantes qui constituent l’héritage global de l’humanité. Mais ils devraient aussi s’exercer à l’exploration et à la collaboration, et s’approprier des connaissances en menant une démarche authentiquement ouverte de recherche de solutions. Ce qui peut être réalisé au sein d’une communauté éducative construite autour d’une structure de responsabilités, c’est-à-dire avec des apprenants qui s’impliquent dans un processus d’expression, de critique et de réflexion par eux-mêmes. Qu’est-ce que j’apprends ? Comment l’ai-je appris ? Pourquoi est-ce important ? Puis-je l’enseigner à d’autres ? Est-ce que j’en ai une connaissance approfondie en l’enseignant ?

Dans cet essai, je compte exposer la façon dont Sugar nourrit une culture éducative par l’association de deux communautés – les développeurs de Sugar et ceux qui apprennent – participant à créer un « contexte favorable au développement humain » et un changement de culture scolaire.

La culture du logiciel libre

La culture du logiciel libre a influencé le développement de Sugar. Les développeurs du Libre vont au-delà du produit de consommation, ils créent et partagent leurs créations ; ils « débattent » du logiciel libre, ils en font la « critique », et ils « discutent le point de vue critique des autres ». Il ne prennent rien pour argent comptant. Les points communs entre le projet Sugar et le mouvement du logiciel libre sont les suivants : des outils pour s’exprimer, car les enfants créent des contenus autant qu’ils les consomment ; et la collaboration, car les enfants partagent leurs réalisations, s’aident mutuellement, et se lancent dans un processus de réflexion sur eux-mêmes et de critique collective.

Le projet Sugar s’inspire également de la façon dont les acteurs de la communauté du logiciel libre collaborent. Tout comme les développeurs de logiciels, les enfants discutent, se socialisent, jouent ensemble, partagent des médias, s’associent pour créer de nouveaux médias et des programmes, s’observent les uns les autres, dans un cadre à la fois formel et informel. Le projet Sugar facilite le partage, la collaboration et la critique. Les développeurs de logiciels libres et ceux qui apprennent avec Sugar rédigent des documents, échangent des livres et des images, créent de la musique ou écrivent du code ensemble. Les deux communautés s’investissent dans une « pratique de réflexion » : il s’agit de mettre en pratique leur expérience tout en étant guidé et épaulé par des « spécialistes » d’un domaine (ils peuvent être professeurs, parents, membres de la communauté dans un salon de discussion, ou encore de camarades étudiants investis dans un échange critique soutenu).

De la même façon qu’avec le logiciel libre, Sugar encourage chaque enfant à être une force créative au sein de sa communauté. L’apprentissage avec Sugar n’est pas un acte passif où l’enfant reçoit le savoir. Il est actif. On parle de créativité, d’aisance, d’innovation, et de résolution de problèmes, tout ce qui implique l’expression personnelle et les liens forts à la communauté. Sugar apporte les outils d’expression à portée des enfants pour qu’ils soient libres d’agir à l’intérieur de leur communauté et à travers leurs actions, de changer le monde. Le logiciel libre est une condition nécessaire pour établir cette culture de l’expression et de l’émancipation. Le mot d’ordre de la génération suivante d’élèves sera « montre-moi le code, que je puisse en tirer un apprentissage et l’améliorer. »

Réalisations et défis

Depuis que nous avons établi les Sugar Labs en tant que projet dans le cadre du Software Freedom Conservancy (NdT : lit. Protection des Libertés Logicielles) en 2008, nous avons démontré notre engagement à un ensemble de valeurs fondamentales qui comprennent la liberté et l’ouverture ; nous sommes devenus dans une large mesure indépendants de tout matériel et distribution (lorsque nous avons commencé, nous étions liés à une seule plateforme – le netbook XO du projet One Laptop per Child (OLPC)) ; nous avons énormément avancé sur le chemin qui conduit à une version logicielle stable 1.0 ; nous sommes forts d’une vaste communauté qui comprend près de 2 millions d’élèves utilisateurs ainsi que, bien entendu, des développeurs de logiciels et de nombreux professeurs et étudiants qui ont leur franc-parler.

Alors que nous nous débattons quotidiennement avec des défis techniques, notre défi principal est l’un des engagements avec notre communauté : comment pouvons-nous nous assurer qu’il y a un dialogue fructueux entre le développeur et les communautés éducatives liées à Sugar ? En d’autres termes, comment pouvons-nous transmettre à la communauté éducative la culture de la collaboration et de l’esprit critique qui est essentielle au développement de la plateforme Sugar, et à mieux nous permettre d’apprendre de nos utilisateurs finaux ? L’un des rôles que joue la communauté Sugar est de sensibiliser l’ensemble de l’écosystème du logiciel libre aux besoins des enseignants. Un autre rôle est de sensibiliser l’ensemble de l’écosystème éducatif au pouvoir de l’expression, de la critique et de l’auto-critique. Dans nos interactions avec les deux communautés, nous prenons grand soin de nous demander nous-mêmes : « Quel effet cela a-t-il sur l’apprentissage ? ».

Afin d’élargir nos efforts, un équilibre entre la fréquence des déploiements Sugar et la fréquence des nouveautés apportées par les Sugar Labs doit être maintenu. Nous avons un bon bilan dans notre réactivité aux besoins identifiés par les déploiements ; dans le même temps, nous sommes pro-actifs en sollicitant une plus grande participation de la communauté.

Les Sugar Labs sont aussi axés sur les besoins des enseignants. Nous avons des discussions régulières sur la façon de solliciter leurs retours. Certains initiatives, tel qu’une liste de discussions fréquentée par des enseignants et des conversations hebdomadaires sur la pédagogie sont très productives. Un exemple de notre succès est que des enseignants commencent à apporter des modifications à Sugar et à ses activités. Un autre exemple est que des professeurs d’université enseignent l’informatique avec des logiciels libres dont Sugar.

Sugar Labs se décline au pluriel

Sugar Labs est une communauté globale qui se charge de définir des objectifs clairs et de maintenir l’infrastructure dont a besoin le projet dans son ensemble. Mais la communauté Sugar encourage et facilite également la création de « labs locaux » qui apportent leurs spécificités et une autonomie pour les déploiements régionaux, y compris en partenariat avec des entreprises locales à but lucratif, ce que le Sugar Labs « central » ne peut pas faire.

Ces labs locaux :

• adaptent la technologie et la pédagogie à la culture et aux ressources locales (ex : développement d’activités et de contenus spécifiques à une région) ;
• aident à traduire Sugar en langues régionales ;
• gèrent les déploiements Sugar dans les écoles de la région ;
• créent des communautés locales adhérentes aux principes des Sugar Labs, rendant Sugar plus ouvert et autonome ;
• permettent la communication entre ces communautés locales et la communauté mondiale Sugar Labs ;
• hébergent, co-hébergent ou s’associent dans l’organisation de conférences, ateliers, discussions et rencontres relatifs à l’utilisation et au développement de Sugar.

Avec le temps, la charge technique se répartit sur les labs locaux (la sortie récente de « Dextrose », pour les OLPC XO construits au Paraguay, est un exemple de comment les labs locaux – menés par une communauté de volontaires – peuvent travailler ensemble pour résoudre des défis techniques et pédagogiques).

En « amont » et en « aval »

Marco Presenti Gritti, développeur Sugar et co-fondateur des Sugar Labs, me rappelait que lorsque nous avons créé les Sugar Labs, nous avons pris une décision réfléchie sur l’étendue du développement. « En suivant le modèle de l’environnement graphique GNOME, nous n’allions pas tout créer et gérer nous-même, mais nous allions nous intégrer et nous appuyer sur les distributions GNU/Linux et le projet OLPC pour le faire ».

Classiquement, un projet en amont^[2] développe du code et un processus de publication. En aval, les distributions créent des paquets avec des personnalisations et distribuent un produit pour l’utilisateur final (cela implique habituellement un processus QA bien défini et un mécanisme de support).

Le spécificité éducative de notre projet a nécessité d’élargir le modèle et les communautés impliquées. Le développement et les déploiements de Sugar sont évidemment engagés dans la construction d’images, de QA, des tests, dans la recherche d’erreurs à corriger, dans la documentation, le support… qui relèvent de programmeurs experts. Mais, comme mentionné précédemment, nous travaillons également avec des étudiants et lycéens et à l’occasion un professeur qui connaît suffisamment bien le Python peut contribuer aux correctifs.

Afin de créer un produit viable et gérable, nous devions établir un équilibre entre notre travail comme projet logiciel « en amont » et les efforts « en aval » des distributeurs GNU/Linux. C’est ainsi que nous travaillons activement avec la communauté Fedora (laquelle a pris à son compte une grosse partie de la charge associée au support du matériel OLPC), la communauté Debian, openSUSE, Trisquel, Mandriva, Ubuntu (ex : le Sugar Ubuntu remixé), etc.. À l’occasion nous devons assumer un rôle de leader, comme quand nous avons pris à bras-le-corps les initiatives naissantes pour créér un Live USB – « Sugar on a Stick ».

Optimisé pour la communauté

À la conférence LIBREPLANET en 2010, Eben Moglen a accordé un entretien sur tout ce qui avait été accompli par la communauté du logiciel libre. Le logiciel libre n’est plus une possibilité ; il est « indispensable », a-t-il affirmé. Ce logiciel « fiable et qui a un coût de production quasi nul » présente de nouvelles et nombreuses opportunités, en particulier dans le secteur de l’éducation, qui est toujours grevé par un budget serré. Seul le logiciel libre est « écrit une fois mais exécuté partout ».

Nous voulons aussi écrire du code fiable qui permette à Sugar d’être exécuté « partout », et nous avons réalisé de grands progrès en suivant les pas de la grande communauté GNU/Linux. Mais la communauté Sugar a un objectif supplémentaire : nous souhaitons que nos utilisateurs finaux participent également à l’amélioration du code, parce que cela participe de l’apprentissage. Si tout le monde est capable d’écrire du code et si ce code est écrit avec les modifications des utilisateurs finaux en tête, nous aurons un monde dans lequel chacun est engagé dans le « débogage », ce que Cynthia Solomon a décrit une fois comme « l’une des grandes opportunités éducatives du XXIe siècle ».

Oui la licence GPL (General Public License) utilisée par les Sugar Labs garantit que le logiciel peut être modifié par l’utilisateur final. Mais, pour la plupart des utilisateurs, ceci n’est qu’une liberté théorique si la complexité du logiciel représente une barrière insurmontable. Par conséquent, les critères habituels (fiabilité, efficacité, maintenance, etc.) sont nécessaires mais non suffisants pour l’éducation.

Aux Sugar Labs, nous faisons un pas supplémentaire en nous assurant que notre code est à la fois libre et ouvert, mais également « ouvert à la manipulation des utilisateurs finaux ».

Voici quelques actions entreprises par Sugar Labs pour encourager et faciliter les modifications des utilisateurs finaux :

• Susciter des attentes et des envies en établissant une culture dans laquelle c’est la norme d’utiliser les libertés permises par le logiciel libre et articuler la liberté pour modifier les aspects du logiciel libre (1ère liberté).
• Offrir des outils qui facilitent l’accès aux sources (ex : un menu « voir les sources » toujours disponible, rendant la source de chaque application à portée d’un « clic de souris »).
• Utiliser des langages de script (Python, Javascript, et SmallTalk dans le cas de Sugar) pour que ces changements puissent être immédiats et faits directement.
• Mettre en place des paliers pour permettre à l’utilisateur final de commencer en faisant des petits pas (alors que le langage de programmation C peut avoir une « couche haute », il n’a pas de très « basse couche »).
• Réduire le risque associé aux erreurs en proposant des « zones tampons » ; si en touchant au code vous introduisez des bugs collatéraux ou irréversibles alors les gens seront vite conditionnés à ne pas se livrer à des comportements à « risque » en modifiant le code.
• Fournir de « vrais » outils : s’assurez-vous que la vraie version puisse être modifiée et non une version répliquée indépendante mais peu motivante.
• Être une communauté de soutien ; on peut dire à juste titre de la communauté Sugar qu’elle est accueillante et tolérante avec les « nouveaux venus », poser une question c’est déjà devenir membre de la communauté, nous sommes pointilleux pour ce qui concerne l’octroi de privilèges sur le « projet principal » mais nous donnons les droits pour encourager la création de branches expérimentales.

Quand on m’a demandé combien de correctifs ont été fournis par les utilisateurs de Sugar, j’ai répondu que des membres de la communauté ont contribué aux correctifs mais que je n’avais pas connaissance de correctifs apportés par des enfants. Encore faut-il faire la distinction entre correctifs envoyés et acceptés, car l’apprentissage commence en créant le correctif, en le soumettant, et en le partageant avec d’autres même lorsqu’il ne se retrouve pas accepté. Sugar a inculqué aux enfants et à leurs professeurs le sentiment qu’ils peuvent être créatifs et utiles avec l’informatique.

Cependant, après deux années d’expérience concrète de Sugar, nous commençons à voir des contributeurs émerger de sa communauté d’utilisateurs. Par exemple, en Uruguay, qui a été le premier pays à fournir des outils éducatifs libres à chaque enfant, quelques préadolescents sont en train de coder activement (un enfant de 12 ans d’une petite ville à des heures de Montevideo fréquente notre canal IRC, y pose des questions et poste du code, à la mi-décembre 2010, il a déjà envoyé huit activités sur notre portail). Quand le président uruguayen José Mujica a entendu parler de ces réalisations, il a souri et a dit avec une voix remplie de fierté : « Nous avons des hackers ». Il y a peut-être 12 enfants qui développent du logiciel libre aujourd’hui en Uruguay. L’an prochain ils seront 100. Dans 2 ans, ils seront 1000. L’Uruguay est en train d’expérimenter un changement de culture lié à un changement dans les attentes que le pays a pour ses enfants, un changement accéléré par la culture du logiciel libre.

Maximiser nos efforts

Qu’est-ce qui motive nos contributeurs et qu’est-ce qui motive les professeurs (que nous aimerions voir adopter Sugar) ?

Pour tenter d’y répondre je me suis appuyé sur l’article L’économie comportementale : les sept principes des décideurs publié par le New Economics Foundation :

• Le comportement des autres personnes compte. Nous devons sensibiliser les professeurs aux meilleures pratiques de Sugar pour qu’ils puissent faire des émules. Pouvons-nous identifier les « génies », « contacts », « commerciaux » dans nos communautés cibles ? Quelles ressources pouvons-nous mettre en place pour les inciter à adopter Sugar ? Ainsi je travaille avec une petite école de quartier dans la ville de Boston dont l’exemple est suivi par d’autres quartiers bien plus importants. Si nous pouvons avoir une influence sur un professeur « génie » du quartier, nous pourrions avoir un gros avantage. Cela signifie également que nous devons être vigilants quant à la qualité pédagogiques de nos activités proposées.

• Les habitudes sont importantes. Ces habitudes qui participent au status quo ne doivent pas être négligées. Qu’est-ce qui motive et encourage le changement ? Quelles actions pouvons-nous mener pour soutenir et engager les changements dans les pratiques et les comportements ?

• Les gens sont motivés pour « faire ce qu’il faut ». Mettons alors cette notion de « faire ce qu’il faut » (NdT : do the right thing) en débat avec les enseignants, essayons de voir avec eux si leurs conceptions peuvent évoluer. En géométrie, il n’y a pas de chemin réservé aux rois, disait Euclide.

• Les attentes des gens influencent leur comportement : ils veulent que leurs actions soient en phase avec leurs valeurs et leurs engagements. C’est un travail de longue haleine pour nous car nous ne sommes pas toujours en phase au départ avec ces attentes. Cependant, tant que nous respectons et sommes fidèles à nos valeurs, nous pouvons convaincre et avoir de l’influence.

• Les gens sont réticents au changement de peur de perdre ce qu’ils possèdent. Utiliser Sugar à partir d’un clé USB (« Sugar on a Stick », qui emprunte seulement un ordinateur sans rien modifier dedans) n’implique aucune changement irréversible tout en permettant de faire une nouvelle expérience pédagogique.

• Les gens hésitent souvent lorsqu’il s’agit de prendre de grandes décisions. Ils sont souvent intimidés par les perspectives d’apprentissage de nouvelles choses (jusqu’à vraiment les faire). De plus es pertes immédiates peuvent décourager et faire perdre de vue les récompenses à long terme. Nous devons accorder une grande importance à ce moment crucial du démarrage en accompagnant ceux qui acceptent de prendre un tel risque.

• Les gens ont besoin de se sentir écoutés et impliqués pour s’engager dans le changement. Nous avons une communauté qui tente d’accorder le plus grand soin à l’accueil des participants et à l’examen de leurs contributions. Ceci est une de nos grandes forces.

Est-ce que cela fonctionne ?

L’évaluation de projets éducatifs a toujours été difficile, en partie parce qu’il est difficile d’arriver à un concensus sur les mesures d’évaluation.

Il semble plus facile de prendre le problème par la négative où le consensus sur ce qu’il ne faut pas faire est plus facile à trouver. Ainsi Michael Trucano, qui blogue sur le portail éducation de la Banque mondiale, a publié un « top 10 » des pires pratiques de l’utilisation des nouvelles technologies dans l’éducation. Liste que je prends ici comme référence négative pour le projet Sugar avec comme exemples probants et prometteurs les deux déploiements d’envergure que sont le Paraguay Educa et le Plan Ceibal en Uruguay.

1. Parachuter du matériel dans les écoles et espérer qu’un miracle se produise.

C’est une critique souvent entendue pour le projet One Laptop per Child (un ordinateur portable par enfant), mais dans le faits, il y avait d’importants mecanismes d’aide et de mise en place en Uruguay et au Paraguay avant même que le matériel ne soit livré. En Uruguay, en plus du vaste support proposé directement par le gouvernement (incluant un programme de formation des professeurs, un centre d’appel, une vidéothèque des bonnes pratiques, etc.), deux initiatives communautaires au niveau national ont vu le jour : Ceibal Jam, qui fournit des logiciels et du contenu local aux enfants d’Uruguay, et Red de Apoyo al Plan Ceibal (RAP-Ceibal), qui assure un réseau d’aide pour les professeurs. Paraguay Educa a une équipe de conseillers qui travaille à temps plein dans les écoles, en aidant les professeurs. Et les éducateurs des deux pays participent régulièrement à des forums mondiaux.

2. Concevoir via l’OCDE des environnements d’apprentissage à implémenter partout.

Les « pays développés » proposent du contenu et quelques règles de bonnes pratiques, mais ce sont avant tout les équipes pédagogiques locales en Uruguay et au Paraguay qui échangent et conçoivent leurs propres matériels et programmes pour répondre à leurs besoins locaux (par exemple, un professeur de la campagne péruvienne a écrit un livre sur l’utilisation de Sugar en salle de classe qui est internationalement lu et reconnu par les autres professeurs).

3. Penser les contenus éducatifs après la mise en place du matériel.

En Uruguay et au Paraguay, c’est la pédagogie qui a guidé la vitesse de déploiement d’un projet vu avant tout comme une plateforme d’apprentissage (incluant les ordinateurs portables, la connectivité, les serveurs, la formation, la documentation, le support, l’assistance de la communauté, etc.).

4. Supposer que vous pouvez uniquement importer du contenu venu d’ailleurs.

Le mot clé ici est « uniquement ». L’Uruguay et le Paraguay profitent bien entendu des contenus créés ailleurs (comme par exemple ceux de la communauté Etoys) mais ils n’oublient de favoriser la production de ressources locales, qu’il s’agisse de nouveaux contenus ou de contenus modifiés à partir de ceux récupérés ailleurs.

5. Ne pas surveiller, ne pas évaluer.

À Plan Ceibal, ils ont un fonctionnement étendu pour surveiller l’état du réseau, des serveurs, et des ordinateurs portables lors du déploiement. Il y a beaucoup d’évaluations en cours du programe, aussi bien internes qu’externes. Paraguay Educa a été l’objet d’une évaluation externe par la Banque Interaméricaine de Développement (IDB Inter-American Development Bank).

6. Faire un gros pari sur une technologie qui n’a pas fait ses preuves.

C’est en particulier le cas lorsque l’on se base sur un unique distributeur et sur des standards fermés et/ou propriétaires. C’est alors une épée de Damoclès qui pèse sur l’avenir du projet. Les deux programmes mentionnés ci-dessous ont fait l’objet d’appels d’offre public et ont plusieurs distributeurs. Les deux utilisent abondamment des logiciels libres.

7. Ne pas être transparent sur le coût global de l’opération.

L’Uruguay a été assidue en publiant les chiffres de leur coût total de possession, maintenance et services du projet (chiffres, basés sur les coûts mesurés sur le terrain, qui se sont avérés plus bas que ce que certains avis pessimistes avaient prévu).

8. Négliger les problèmes d’équité.

En Uruguay ce sont avant tout les familles modestes qui sont ainsi équipées en informatique avec un accès Internet gratuit.

9. Ne pas former vos professeurs (ni votre directeur d’école).

Le plus gros investissement dans le programme au Paraguay a été la formation des professeurs. C’est sûrement la principale clé de la réussite du projet et nous veillons à ce que cette formation soit toujours plus efficace et adaptée aux réalités du terrain.

Trucano laisse le point numéro 10 comme exercice ouvert pour le lecteur. J’ajouterais :

10. Ne pas impliquer la communauté.

Dans les deux communautés uruguayenne et paraguayenne l’implication fait partie du projet par nature. Pour ce qui concerne Sugar, c’est un effort d’une communauté globale qui implique des centaines d’ingénieurs et des milliers de professeurs. Un résultat remarquable est le degré d’implication des parents dans les programmes.

Regarder vers le futur

Comme il est de mise avec chaque projet piloté par une communauté, il y a un débat permanent sur la vision de Sugar. Il peut y avoir des divergences d’opinion sur l’étendue de la mission des Sugar Labs (allant d’un point d’attention particulier sur les outils de collaboration à une vision plus large sur tout ce qui est nécessaire pour des déploiements réussis de l’OLPC). Mais tout le monde s’accord à dire qu’il y a une communauté Sugar de développeurs et d’apprenants pleine de vie et d’énergie et que les plateformes d’apprentissage basées sur des logiciels libres encouragent l’appropriation du savoir quel que soit le domaine que l’apprenant explore : musique, navigation sur internet, lecture, écriture, programmation, dessins, etc.

Carla Gomez Monroy, une pédagogue qui a participé à de nos nombreux déploiements, décrit Sugar comme « un environnement émergent et collaboratif, où la communauté identifie, code, utilise, innove, conçoit et re-conçoit ses propres outils » Les membres de la communauté d’apprentissage de Sugar s’engagent dans le débogage de leur créativité et des outils mis en place pour exprimer cette créativité. Ils investissent Sugar en tant que technologie mais aussi et surtout comme une culture de l’apprentissage passant par l’expression et la critique collective.

L’expérience Sugar Labs est « une participation collaborative pour apprendre à apprendre avec des outils qui nous correspondent ».

Walter Bender est le fondateur et le directeur exécutif de Sugar Labs, une fondation à but non lucratif. En 2006, Bender a co-fondé « One Laptop per Child », une organisation à but non lucratif avec Nicholas Negroponte et Seymour Papert.