Le célèbre (et libre) langage de programmation Python est en danger en Europe pour une sombre histoire de droit des marques.

Nous avons traduit ci-dessous l’appel à soutien de Van Lindberg, président de la Python Software Foundation.

La marque Python en péril en Europe : Nous avons besoin de votre aide !

Python trademark at risk in Europe: We need your help!

Van Lindberg – 14 février 2013 – Python Software Foundation
(Traduction : Moosh, lgodard, Alpha, QuébecTroll, jtanguy, Penguin, Uflex, ProgVal, goofy, maz, Nodel, Norore + anonymes)

Vous qui travaillez dans une entreprise qui a un bureau dans un pays membre de l’Union Européenne, nous avons besoin de votre aide.

Une entreprise au Royaume-Uni essaye de faire reconnaître le terme « Python » comme marque commerciale pour tout logiciel, service ou serveur, à peu près tout ce qui a quelque chose à voir avec un ordinateur. Plus précisément, c’est l’entreprise qui a acquis le domaine python.co.uk il y a treize ans. À cette époque, nous nous souciions peu des problèmes de marque et nous n’avions pas acquis ce domaine.

Ce n’était pas un problème jusqu’à présent car le domaine python.co.uk, la plupart du temps, se contentait de transférer son trafic vers les sociétés-mères, veber.co.uk et pobox.co.uk. Malheureusement, Veber a décidé qu’ils voulaient commencer à utiliser le nom « Python » pour leurs logiciels serveurs.

Nous avons contacté les propriétaires de python.co.uk à plusieurs reprises et essayé d’en discuter avec eux. Leur seule réponse a été de déposer une demande de marque communautaire réclamant les droits exclusifs d’utiliser le terme « Python » pour des logiciels, serveurs, et services web – et ce partout en Europe.

Nous avons fait appel à un conseiller juridique au Royaume Uni et nous, la Python Software Foundation (NdT :. la Fondation Python), opposons à cette demande une demande de dépôt de marque communautaire, mais notre propre demande n’est pas suffisamment mûre. Dans cette dernière, nous exposons les droits de propriété de la marque résultants de l’utilisation de “Python” au cours de ces 20 dernières années.

D’après notre avocat londonien, les meilleures preuves que nous puissions transmettre au bureau européen des marques déposées sont les lettres d’entreprises connues « utilisant le logiciel de marque PYTHON dans divers pays de l’Union Européenne » de telle sorte que nous puissions « obtenir des témoignages indépendants de leur part, prouvant l’origine de la signification de la marque PYTHON, en relation avec le logiciel et les produits/services associés ». Nous avons aussi besoin de preuves d’utilisation de Python à travers toute l’Union Européenne.

Que pouvez-vous faire ?

1- Vous travaillez pour une entreprise qui utilise Python ? Vous êtes basés en Europe, vous y embauchez ou vous y possédez un bureau ? Pourriez-vous écrire une lettre avec l’en-tête de votre entreprise que nous pourrions réutiliser par la suite ?

Nous aurions besoin des élements suivants :

1. Une brève description de l’utilisation de Python dans votre entreprise :
2. Comment votre entreprise associe le terme Python uniquement à la PSF ;
3. Votre opinion sur le fait qu’une autre entreprise utilisant le terme Python dans ses services, logiciels et serveurs pourrait âtre source de confusion.

La lettre n’a pas besoin d’être très longue —- quelques paragraphes suffisent, mais nous apprécierions toute forme de description de votre utilisation de Python dans vos logiciels, votre hébergement internet, vos serveurs, vos VPN, dans le développement de logiciel ou de matériel ou encore dans l’utilisation de services de sauvegarde. Pour ceux qui sont intéressés par les classes descriptives légales, elles figurent au bas de ce message^[1][2].

Vous pouvez envoyer une copie PDF de votre lettre à psf-trademarks@python.org

2. Connaissez-vous ou possédez-vous quoi que ce soit qui ait été publié au sein de l’UE et qui utilise “Python” pour faire référence au langage Python? Pouvez-vous nous transmettre des numérisations, photos ou copies? Cela comprend :

• Des livres ;
• Des brochures ;
• Des programmes de conférences ou présentations ;
• Des offres d’emploi ;
• Des magazines ou autres publications ;
• Des prospectus.

Vous pouvez envoyer un scan PDF de ces documents à psf-trademarks@python.org.

3. Vous pouvez également aider à protéger la propriété intellectuelle de Python en nous soutenant financièrement.

Comme le coût d’opposition d’une marque commerciale est de l’ordre de dizaines de milliers de dollars, nous aurons besoin de trouver un moyen de financer les coûts de procédure de l’opposition.

Merci d’envisager une donation à la Python Software Foundation ou de me contacter.

C’est la première fois que la PSF doit prendre des mesures juridiques pour protéger la propriété intellectuelle de Python. S’il vous plait, aidez Python comme vous le pouvez. La menace est réelle et elle est susceptible de nuire à votre entreprise en Europe, surtout si vous êtes dans le domaine de l’hébergement et que Python fait partie de l’offre que vous proposez.

S’il vous plaît, faites-moi savoir si vous avez des questions auxquelles je peux répondre. Si vous connaissez quelqu’un qui devrait avoir l’information, libre à vous de la partager.

Thanks, Merci,

Van Lindberg, Président
van@python.org
Python Software Foundation

En novembre dernier, Richard Stallman faisait paraître dans le magazine Wired un article important sur l’épineuse et dangereuse question des brevets logiciels (ou plutôt « brevets sur des idées informatiques » comme nous le verrons ci-après).

Un article que nous nous sommes empressés de traduire via notre circuit, désormais classique, compte Twitter + Framapad, et qui a été relu et corrigé par la liste « trad-gnu » de l’April.

Protéger le secteur du logiciel des brevets

Giving the Software Field Protection from Patents

Richard Stallman – version du 02 février 2013 – Gnu.org (CC BY-ND)
(Traduction Framalang : satbadkd, Thérèse, DarthMickey, geecko, Marc, igor, EEva, greygjhart)

Une première version de cet article a été publiée sur Wired en novembre 2012.

Les brevets menacent chaque concepteur de logiciel, et les guerres de brevet que nous avons longtemps craintes ont éclaté. Les développeurs et les utilisateurs – soit, dans notre société, la plupart des gens – ont besoin de logiciels libres de tout brevet.

Les brevets qui nous menacent sont souvent appelés « brevets logiciels », mais ce terme est trompeur. Ces brevets ne concernent aucun programme en particulier. En fait, chaque brevet décrit une idée applicable en pratique, et affirme que quiconque utilise cette idée peut être poursuivi en justice. Il est donc plus clair de les appeler « brevets sur des idées informatiques », ou « brevets sur des algorithmes ».

Le système de brevets américain ne différencie pas les « brevets logiciels » des autres. Seuls les développeurs font la distinction entre les brevets qui nous menacent – ceux qui concernent des idées pouvant être implémentées dans des logiciels – et les autres. Par exemple : si l’idée brevetée est la forme d’une structure physique ou une réaction chimique, aucun programme ne peut implémenter cette idée ; ce brevet ne menace pas le secteur du logiciel. Si par contre l’idée qui est brevetée est un algorithme, alors le canon de ce brevet est braqué sur les développeurs et les utilisateurs.

Cela ne veut pas dire que les brevets couvrant des algorithmes concernent seulement les logiciels. Ces idées peuvent être aussi implémentées dans du matériel… et beaucoup d’entre elles l’ont été. Chaque brevet couvre typiquement les implémentations matérielles et logicielles de l’idée.

Le problème particulier du logiciel

Toujours est-il que c’est dans le domaine du logiciel que les brevets sur des algorithmes posent un problème particulier. Il est facile de combiner des milliers d’idées dans un seul programme. Si 10% de ces idées sont brevetées, cela signifie que des centaines de brevets le menacent.

Quand Dan Ravicher, de la Public Patent Foundation (Fondation publique des brevets) a étudié en 2004 un programme de taille importante (Linux, qui est le noyau du système d’exploitation GNU/Linux), il a trouvé 283 brevets américains qui semblaient couvrir des algorithmes implémentés dans son code source. Cette année-là, on estimait la part de Linux dans le système GNU/Linux complet à 0,25%. En multipliant 300 par 400, on peut estimer que le nombre de brevets qui menacent le système dans son ensemble est de l’ordre de 100 000.

Si la moitié de ces brevets était supprimée pour cause de « mauvaise qualité » – c’est-à-dire pour cause de ratés du système de brevets – cela ne changerait pas grand chose. Que ce soit 100 000 ou 50 000 brevets, la catastrophe est la même. C’est pourquoi c’est une erreur de limiter nos critiques des brevets logiciels aux seuls patent trolls ou aux brevets de « mauvaise qualité ». En ce sens Apple, qui n’est pas un « troll » selon la définition habituelle, est actuellement l’entreprise la plus dangereuse quand elle se sert de ses brevets pour attaquer les autres. Je ne sais pas si les brevets d’Apple sont de « bonne qualité », mais plus la « qualité » du brevet est élevée, plus la menace est grande.

Nous devons corriger l’ensemble du problème, pas seulement une partie.

Pour corriger le problème sur le plan législatif, on suggère habituellement de changer les critères d’octroi des brevets – par exemple, d’interdire la délivrance de brevets sur les pratiques algorithmiques et les systèmes nécessaires à leur mise en œuvre. Mais cette approche a deux inconvénients.

Premièrement, les avocats reformulent les brevets de manière astucieuse pour qu’ils correspondent à toute règle applicable ; ils transforment toute tentative de limiter un brevet sur le fond en une simple exigence de forme. Par exemple, de nombreux brevets américains sur des algorithmes décrivent un système qui comprend une unité de traitement arithmétique, un séquenceur d’instruction, une mémoire ainsi que des contrôles pour mener à bien un calcul précis. C’est une manière assez particulière de décrire un programme tournant sur un ordinateur pour effectuer un certain calcul ; elle a été élaborée pour que la demande de brevet se conforme aux critères que, pendant quelques temps, l’on a cru être ceux du système américain de brevets.

Deuxièmement, les États-Unis ont déjà plusieurs milliers de brevets sur des algorithmes, et changer les critères pour empêcher d’en créer d’autres ne permettrait pas de se débarrasser de ceux qui existent. Il faudrait attendre pratiquement 20 ans avant que le problème ne soit entièrement résolu du fait de l’expiration des brevets. Et abolir les brevets existants par la loi est probablement anticonstitutionnel (de manière assez perverse, la Cour suprême a insisté pour que le Congrès puisse étendre les privilèges privés au détriment des droits du public mais ne puisse pas aller dans l’autre direction).

Une approche différente : limiter l’effet des brevets, pas la brevetabilité

Ma proposition est de changer l‘effet des brevets. Il faut inscrire dans la loi que développer, distribuer ou exécuter un programme sur des systèmes informatiques polyvalents ne constitue pas une violation de brevet. Cette approche a plusieurs avantages :

• elle n’impose pas de classer les brevets selon qu’ils sont logiciels ou non ;
• elle apporte aux développeurs ainsi qu’aux utilisateurs une protection contre les brevets sur des algorithmes, existants ou futurs ;
• les avocats spécialistes des brevets ne peuvent plus trouver d’échappatoire en changeant la formulation de leurs demandes.

Cette approche n’invalide pas entièrement les brevets existants sur des algorithmes, parce qu’ils continueront à s’appliquer aux implémentations utilisant du matériel dédié. C’est un avantage dans le sens que cela supprime un argument mettant en question la validité de cette proposition du point de vue législatif. Les États-Unis ont légiféré il y a quelques années afin d’immuniser les chirurgiens contre les procès en contrefaçon de brevet, de sorte que même si des procédures chirurgicales sont brevetées, les chirurgiens sont protégés. Cela fournit un précédent pour ce type de solution.

Les développeurs et les utilisateurs de logiciels ont besoin de protection contre les brevets. Cette proposition est la seule solution législative qui apporte une protection totale à tous. Nous pourrions ensuite retourner à notre monde de concurrence ou de coopération… sans craindre qu’un inconnu ne vienne balayer notre travail.

Voir également : Une réforme des brevets n’est pas suffisante

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

Un certain nombre de textes tournent actuellement sur le Net suite au décès d’Aaron Swartz. Parmi eux on trouve « La Conscience d’un hacker » (ou « Le Manifeste du hacker ») datant de… 1986 et que d’aucuns trouvent particulièrement adapté aux circonstances. Et pour cause…

Nous vous le proposons traduit ci-dessous^[1]. Il a été rédigé par Loyd Blankenship, (alias The Mentor) juste après son arrestation.

« Oui, je suis un criminel. Mon crime est celui de la curiosité. »

Remarque : Nous sommes en 1986 et c’est par le téléphone que passe le réseau. Un téléphone qui se retrouve alors bloqué par ces « sales gosses » pour la communication classique.

La conscience d’un hacker

The Conscience of a Hacker

The Mentor – 8 janvier 1986 – Phrack.org
(Traduction : NeurAlien, Moosh, ga3lig, goofy, zozio nocture (aka brandelune), Slystone, KoS, aKa, Martin, lamessen, Sky)

Ce qui suit a été écrit peu de temps après mon arrestation…

Un autre s’est fait prendre aujourd’hui, c’est partout dans les journaux.
« Scandale : Un adolescent arrêté pour crime informatique », « Arrestation d’un hacker après le piratage d’une banque »…
Satanés gosses, tous les mêmes.

Mais vous, dans votre psychologie de costume trois pièces et votre conscience technologique des années 50, avez-vous un jour pensé à regarder le monde avec les yeux d’un hacker ?
Ne vous êtes-vous jamais demandé ce qui l’avait fait agir et quelles forces l’avaient animé ?
Je suis un hacker, entrez dans mon monde…
Mon monde, il commence avec l’école… Je suis plus éveillé que la plupart des autres enfants et les nullités qu’on nous enseigne m’ennuient…
Satanés gamins, ce sont tous les mêmes.

Je suis au collège ou au lycée. J’ai écouté les professeurs expliquer pour la quinzième fois comment réduire une fraction.
J’ai bien compris. « Non Mme Dubois, je n’ai pas montré mon travail. Je l’ai fait dans ma tête ».
Satané gosse. Il a certainement copié. Ce sont tous les mêmes.

J’ai fait une découverte aujourd’hui. J’ai trouvé un ordinateur.
Attends une minute, c’est cool. Ça fait ce que je veux. Si ça fait une erreur, c’est parce que je me suis planté.
Pas parce qu’il ne m’aime pas…
Ni parce qu’il se sent menacé par moi…
Ni parce qu’il pense que je suis un petit malin…
Ni parce qu’il n’aime pas enseigner et qu’il ne devrait pas être là…
Satané gosse. Tout ce qu’il fait c’est jouer. Ce sont tous les mêmes.

Et c’est alors que ça arrive. Une porte s’ouvre…
Les impulsions électroniques déferlent sur la ligne téléphonique comme l’héroïne dans les veines d’un drogué.
Pour trouver dans un Forum le refuge contre la stupidité quotidienne.
« C’est ça… C’est ici que je dois être…»
Ici, je connais tout le monde… Même si je n’ai jamais rencontré personne. Je ne leur ai jamais parlé, et je n’entendrai peut-être plus parler d’eux un jour… Je vous connais tous.
Satané gosse. Encore pendu au téléphone. Ce sont tous les mêmes.

A l’école, on nous a donné des pots de bébé alors qu’on avait les crocs pour un steak…
Les morceaux de viande que vous avez bien voulu nous tendre étaient pré-mâchés et sans goût.
On a été dominé par des sadiques ou ignoré par des apathiques.
Les seuls qui avaient des choses à nous apprendre trouvèrent en nous des élèves de bonne volonté, mais ceux-ci étaient comme des gouttes d’eau dans le désert.

C’est notre monde maintenant… Le monde de l’électron et des commutateurs, la beauté du baud. Nous utilisons un service déjà existant, sans payer ce qui pourrait être bon marché si ce n’était pas géré par des profiteurs avides, et c’est nous que vous appelez criminels.
Nous explorons… et vous nous appelez criminels.
Nous recherchons la connaissance… et vous nous appelez criminels.
Nous existons sans couleur de peau, sans nationalité, sans dogme religieux… et vous nous appelez criminels.
Vous construisez des bombes atomiques, vous financez les guerres, vous assassinez et trichez, vous manipulez et vous nous mentez en essayant de nous faire croire que c’est pour notre propre bien… et pourtant c’est nous qui sommes les criminels.

Oui, je suis un criminel. Mon crime est celui de la curiosité.
Mon crime est celui de juger les gens selon ce qu’ils pensent et disent, pas selon leur apparence.
Mon crime est d’être plus malin que vous, quelque chose que vous ne me pardonnerez jamais.

Je suis un hacker, et ceci est mon manifeste.
Vous pouvez arrêter un individu, mais vous ne pouvez pas tous nous arrêter…
Après tout, nous sommes tous les mêmes.

The Mentor

Crédit photo : Elizabeth Brossa (Creative Commons By-Nc-Sa)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sky, LIAR, lerouge, yann, Goofy, peupleLa, KoS, Nys, Julius22, okram, 4nti7rust, zn01wr, lamessen

Des sauvegardes pour votre santé mentale

Austin Appel

Austin Appel, alias « scorche », est un professionnel de la sécurité informatique qui passe son temps à casser (il est dûment autorisé, évidemment) des choses précédemment réputées sécurisées. On le croise souvent enseignant le crochetage de serrure durant des conférences de sécurité et de hacking. Dans le monde de l’open source, il fait une foule de choses pour le projet Rockbox et a œuvré bénévolement pour le projet One Laptop Per Child (un ordinateur portable par enfant).

Les sauvegardes c’est bien. Les sauvegardes c’est super. Un administrateur compétent fait toujours des sauvegardes régulières. On apprend ça dans n’importe quel manuel traitant de l’administration des serveurs. Le problème c’est que les sauvegardes ne sont vraiment utiles qu’en cas d’absolue nécessité. Lorsque quelque chose de grave arrive au serveur ou à ses données et qu’on est forcé de se replier sur autre chose, les sauvegardes viendront à point nommé. Cependant, cela ne devrait jamais arriver, n’est-ce pas ? À n’importe quel autre moment, à quoi cela sert-il pour vous et votre environnement serveur d’avoir des sauvegardes ?

Avant d’aller plus loin, il est important de noter que ce conseil vaut pour les administrateurs serveurs des plus petits projets open source — la majorité silencieuse. Si vous maintenez des services qui vont engendrer une grande frustration, et même peut-être faire du tort s’ils sont indisponibles, vous devriez considérer ceci avec la plus grande circonspection.

Pour le reste d’entre nous qui travaillons sur d’innombrables petits projets ayant des ressources limitées, nous avons rarement deux serveurs séparés pour la production et les tests. En vérité, avec tous les services qu’un projet open source doit maintenir (système de gestion de version, services web, listes de diffusion, forums, ferme de compilation, bases de données, traceurs de bogues ou de fonctionnalités, etc.), des environnements de test séparés sont souvent de l’ordre du rêve. Malheureusement, l’approche courante de l’administration systèmes est d’avancer avec précaution et mettre les systèmes à jour uniquement en cas de nécessité absolue, afin d’éviter tout problème de dépendance, de code cassé, ou n’importe laquelle des millions de choses qui pourraient mal se dérouler. La raison pour laquelle vous êtes nerveux n’est pas que vous pourriez manquer d’expérience. Il est important de savoir que vous n’êtes pas seul dans ce cas. Que nous l’admettions ou non, beaucoup d’entre nous ont été (et sont probablement encore) dans cette situation. Il est triste que cette inaction — découlant de la peur de détruire un système fonctionnel — conduise souvent à des services en fonctionnement qui ont souvent plusieurs versions de retard, ce qui implique de nombreuses failles de sécurité potentiellement sérieuses. Cependant, soyez assuré que ce n’est pas la seule manière de jouer le jeu.

Les gens ont tendance à jouer un jeu différent selon qu’ils aient une infinité de vies ou qu’ils doivent recommencer depuis le début dès lors qu’une seule erreur a été commise. Pourquoi devrait-il en être autrement pour de l’administration systèmes ? Aborder le concept de sauvegardes avec un état d’esprit offensif peut complétement changer votre conception de l’administration systèmes. Au lieu de vivre dans la peur d’une dist-upgrade complète (ou de son équivalent pour yum, pacman, etc.), celui qui est armé de sauvegardes est libre de mettre à jour les paquets d’un serveur, confiant dans le fait que ces changements pourront être annulés si les choses tournent au vinaigre. La clé du succès réside tout entière dans l’état d’esprit. Il n’y a aucune raison d’avoir peur tant que vous avez vos données sauvegardées sous la main comme filet de sécurité lorsque vous sautez le pas. Après tout, l’administration système est une expérience d’apprentissage permanente.

Bien sûr, si vous ne validez pas vos sauvegardes, vous reposer sur elles devient un jeu très dangereux. Heureusement, les administrateurs systèmes expérimentés savent que le commandement « Garde des sauvegardes à jour » est toujours suivi par « Valide tes sauvegardes ». À nouveau, c’est un mantra que les gens aiment réciter. Ce qui, en revanche, ne tient pas de façon élégante dans un mantra entraînant est la manière de valider rapidement et simplement ses sauvegardes. La meilleure manière de dire qu’une sauvegarde est fonctionnelle est, bien sûr, de la restaurer (de préférence sur un système identique qui n’est pas en cours d’utilisation). Mais, une fois encore, en l’absence d’un tel luxe, on doit faire preuve d’un peu plus de créativité. C’est là (tout du moins pour les fichiers) que les sommes de contrôle peuvent vous aider à vérifier l’intégrité de vos fichiers sauvegardés. Dans rsync, par exemple, la méthode utilisée par défaut pour déterminer quels fichiers ont été modifiés consiste à regarder la date et l’heure de la dernière modification, ainsi que la taille du fichier. Cependant, en utilisant l’option ‘-c’, rsync utilisera une somme de contrôle MD4 de 128 bits pour déterminer si les fichiers ont changé ou non. Bien que ce ne soit pas toujours la meilleure idée à mettre en œuvre à chaque fois en toute occasion — à cause d’un temps d’exécution beaucoup plus long qu’un rsync normal et d’une utilisation accrue des accès disques — cette méthode permet de s’assurer que les fichiers sont intègres.

Le rôle d’un administrateur systèmes peut être éprouvant par moments. Il n’est cependant pas nécessaire de le rendre plus stressant que nécessaire. Avec le bon état d’esprit, certaines commandes de précaution apparemment à but unique et limité peuvent être utilisées comme des outils précieux qui vous permettent de progresser de façon agile, tout en gardant votre santé mentale intacte et la vitesse tant appréciée dans les projets open source.

Les entreprises utilisant et fabriquant du logiciel libre à destination des écoles primaires sont rares. Il faut reconnaître que le marché est compliqué et beaucoup plus difficile à conquérir puisqu’il faut démarcher chaque mairie là où les conseils généraux suffisent pour les collèges. C’est donc un travail de fourmi que doivent fournir ces sociétés pour exister. Nous avions rencontré en mars dernier les co-présidents d’iMaugis. Aujourd’hui, c’est Éric Seigne, que nous avons le plaisir d’interviewer. Il en profite pour nous annoncer une nouvelle qui devrait, nous l’espérons, faire beaucoup de bruit 😉

Bonjour Éric. Pour ceux qui ne te connaissent pas, peux-tu te présenter ?

Éric Seigne, 34 ans , directeur de la société RyXéo, éditeur de AbulÉdu, ensemble de logiciels libres multidisciplinaires à destination des établissements scolaires. Je suis un des membres fondateurs de l’ABUL, Association Bordelaise des Utilisateurs de Logiciels Libres, ainsi que d’autres associations libres.

Comment as-tu découvert le libre ?

Pendant mes années de lycée, dans le journal local (Sud Ouest) on pouvait lire que se tenaient à Bordeaux des repas entre Experts Linux… À cette époque, j’avais la chance de pouvoir bidouiller l’ordinateur de ma sœur aînée, alors équipée de DOS, tandis que mes amis disposaient d’ Amiga et Amstrad (avec écran couleur, son, jeux…) … Je me contentais du prompt A:>_ …

J’ai ensuite installé un OS/2 puis ai enfin eu mon propre ordinateur, pc offert par mon grand-père.

J’ai trouvé le moyen d’installer une slackware sans en connaître les commandes rudimentaires… J’ai persévéré et ai, comme beaucoup d’autres, apprécié. Après mon bac, je me suis installé à Bordeaux et y ai effectué mes études. J’ai enfin pu participer à ces fameux repas de linuxiens bordelais où la constitution d’une association locale (ABUL) a été décidée. À cette époque, des personnes telles que Pierre Ficheux ont suscité chez moi une réelle admiration ! À tel point qu’une Redhat a remplacé la slackware sur ma machine. La découverte de l’interface graphique n’a finalement pas changé grand-chose… si ce n’est de pouvoir lancer un Netscape… les habitudes étaient déjà trop grandes… j’appréciais les fameuses lignes de commande et ne comptais plus les abandonner.

J’ai également participé à quelques demo-parties et ai pu admirer les prouesses des démos 4k, des équipes dev-gfx-zique… la créativité de ces gens est tout simplement incroyable.

Je savais que je n’aurais pas dû jouer autant avec mon Amstrad 6128 😉
Tu es à l’initiative de nombreux projets ou tu y participes : RyXéo, AbulÉdu, AbulÉdu-fr, AbulÉdu ENT, Le Terrier, Pédagosite, Scideralle…
Vu de l’extérieur, cela commence à ressembler à l’anarchie des projets Framasoft 😉
Tu peux nous les présenter pour y voir plus clair ?

Connais-tu “la cathédrale et le bazar“ ? Ce livre fait partie de mes lectures qui ont eu une grosse influence sur ma trajectoire, au même titre que l’incroyable “hold up planétaire” de Roberto di Cosmo). Je suis un créateur sur le mode « bazar » qui, de temps en temps, essaye de remettre un peu d’organisation « cathédrale » pour repartir sur un cycle bazar et ainsi de suite :

• 1998 création de l’Abul et définition de nos prérogatives à savoir l’éducation, la création du groupe Abul-edu, qui donnera naissance au projet Abuledu

• 1998 l’AFUL signe une convention avec le Ministère de l’Éducation Nationale (Stéphane F., Thierry S., Bernard L., Nat M. Jean-Pierre L. et toute l’équipe de l’AFUL que je ne remercierai jamais assez pour ce coup d’éclat) qui nous ouvre les portes et définit le cadre de travail dont nous bénéficions dans ce secteur

• 1998 Jean Peyratout, instituteur à Gradignan (à 200 m de chez moi), fondateur de l’ABUL nous fait vibrer au son de « je suis instituteur laïc, républicain, gratuit … et néanmoins obligatoire et à ce titre j’ai du mal à mettre mes élèves devant des ordinateurs Microsoft Windows pour leur faire utiliser Microsoft Word (ou Write), Microsoft Excel, Microsoft Encarta, Microsoft truc et ainsi de suite, il y a la une entorse à mon éthique (et mon devoir de neutralité) que j’ai du mal à avaler, j’aimerais savoir si “linux” pourrait pas nous offrir un choix ».

• 1999/2000 le groupe Abul-edu (une trentaine de bénévoles de l’association) installe “des ordinateurs en réseau” dans l’école primaire de Jean Peyratout. On va du recyclage de vieux pc à l’installation d’un “serveur” (de mémoire un P3 avec 128 ou peut-être 256 Mo de RAM) … Camille C. nous amène une techno: “LTSP“… on essaie également XTermKit de Jacques Gélinas… Pour faire simple on pourrait dire que les enfants utilisent AbulÉdu en semaine et des adultes barbus s’adonnent à leur hobby le week end…

• 2000 premières RMLL, le cycle éducation présente des projets extrêmement ingénieux, dont celui de Jacques Gélinas (Hacker kernel, papa de linuxconf) qui enivre la foule… en fin de journée, nous faisons des démonstrations autour d’AbulÉdu. À la fin de la conférence, plus d’une dizaine d’enseignants viennent nous voir et nous disent qu’ils veulent faire la même chose dans leur école. Dans l’euphorie de l’événement on leur lâche un « chiche, revenez dans un an on vous donnera un cd d’installation »

• Cette même année 2000, je crée l’entreprise individuelle Rycks

• Un an plus tard, lors des RMLL 2001, on lance le CDROM AbulÉdu 1.0 basé sur Mandrake 7.2 (je salue et remercie encore les hackers de Mandrake qui nous ont aidés et soutenus)… La communauté s’élargit alors jusqu’en Afrique de l’Ouest, au Burkina Faso, en Côte d’Ivoire et bien naturellement partout en France. Des enseignants comprenant notre démarche vis à vis des enjeux du libre dans le milieu scolaire veulent créer des logiciels pour aider leurs enfants à apprendre à lire, compter… un coup de pouce technique plus tard Le Terrier d’AbulÉdu est né.

• Dans notre approche constructiviste, suite à des retours utilisateurs, nous créons Pédagosite, une nouvelle fois, dans notre bazar. L’idée est de mettre en commun les fiches pratiques et pédagogiques des enseignants contributeurs.

• 2003 l’association ABUL, le groupe abul-edu et AbulÉdu décident de structurer. L’ABUL a pour mission de s’occuper de Linux sur Bordeaux (je schématise) et AbulÉdu prend alors son envol. Le groupe Abul-edu se réunit et créé l’association SCIDERALLE.

• 2003 Rycks devient RyXéo, quittant le statut d’entreprise individuelle pour celui de SARL. Le changement n’intervient pas de façon isolée et AbulÉdu passe alors sur Debian. Nous proposons une solution clé en main de serveurs pré-installés accompagnés de maintenance. Le succès est mitigé : des clients qui nous rapportent de l’argent mais un malaise naît au sein de la communauté qui a du mal à comprendre qu’on puisse vendre du logiciel libre. 5 années plus tard, en 2008, nous relançons « AbulÉdu gratuit », version 8.08. Porteuse d’espoirs, elle nous apporte très rapidement son lot de désillusions, des donneurs d’ordre téléchargent la version gratuite, l’installent dans des écoles mais ne contractent ni support, ni expertise, ni formation auprès de RyXéo, même à 30 euros par mois !

Et la naissance d’AbulÉdu-fr ?

L’association a été constituée en 2010 et regroupe les utilisateurs d’AbulÉdu. Depuis 2011 nous essayons de resserrer les liens entre la communauté et RyXéo, l’association AbulÉdu-fr est la bonne interface pour ça.

Le bilan de l’association est présenté sur le site de l’association. toute aide est la bienvenue, en particulier d’un point de vue financier : l’association a du mal à payer les frais de déplacement pour les développeurs bénévoles lorsqu’ils viennent chez nous (RyXéo) une fois par mois.

RyXéo a toujours eu des liens avec l’éducation, notamment avec les écoles. Sauf erreur de ma part, c’est la seule entreprise, qui, en 2009, répondait intégralement au cahier des charges du ministère lors du Plan École Numérique Rurale. Pourtant de nombreuses autres entreprises ont finalement été retenues lors de ce plan (dont certaines se sont d’ailleurs mystérieusement volatilisées depuis). Comment l’expliques-tu ? Penses-tu que le fait de proposer des solutions libres a été, à ce moment là, un inconvénient ?

Je suis mal placé pour dire si on était les seuls à être compatibles avec le cahier des charges, je dirais juste qu’on a essayé d’apporter la réponse la plus claire possible.

Concernant les truands qui se sont placés sur ce marché pour voler de l’argent public et disparaître après avoir livré partiellement des écoles oui, ça m’a rendu assez malheureux.

Ensuite, ce plan était dans le « plan de relance de l’économie », j’ai observé qu’on a surtout relancé les importations de matériels produits à l’étranger. J’aurais préféré qu’on inverse le ratio matériel-service en s’appuyant par exemple sur du recyclage d’ordinateurs et en mettant beaucoup de ressources humaines en jeu en incluant des heures de passage dans les écoles pour que les entreprises fassent réellement du boulot d’accompagnement technique. Voire qu’on injecte des moyens financiers sous forme de création de postes d’animateurs TICE (ou dans les CDDP ou dans les équipes des Inspections Académiques ou autres structures existantes) pour que les enseignants puissent réellement mettre en pratique des usages avec des professionnels de la pédagogie…

Depuis 2010, de nouveaux logiciels du Terrier ont été développés et certains réécrits. Cela marque une réelle rupture aussi bien au niveau visuel que technologique par rapport aux premiers logiciels. Comment se font ces nouveaux développements ?

• En 2009, nous (RyXéo) avons fait un bilan à la fois fonctionnel et technique des logiciels du Terrier d’AbulÉdu. Nous en avons tiré les 3 principales conclusions:

1. logiciels pertinents et reconnus sur les aspects métier
2. graphismes et ergonomie à repenser
3. améliorations techniques du code applicatif à mettre en œuvre

Je tiens à signaler au passage que les logiciels en question sont vraiment conséquents, par exemple Association nécessite 1500 dessins et près d’un millier de mots (sous forme de sons) enregistrés ! À de nombreuses reprises la communauté des développeurs a lancé des appels à contribution pour avoir des dessins et des ressources libres réutilisables… sans grand succès.

• Ryxéo engage un graphiste (en fait il s’agit d’un dessinateur de BD et illustrateur). En parallèle nous testons différents langages pour nos futurs logiciels (python, pygame, etc) sans en être vraiment convaincus. Puis sur le test du logiciel Raconte-moi, nous tentons l’aventure Qt/C++.
• Au même moment, nous accueillons en stage, un enseignant avec qui nous avons l’habitude de travailler. Avec notre équipe technique, il développe le logiciel Calcul-Mental et travaille en forte collaboration avec le graphiste.

Le résultat est évident : nous sommes séduits… et l’équipe s’étoffe en l’embauchant à l’issue de son stage.

Parlons de choses qui fâchent 😉

Parmi les nouveaux logiciels, certains sont téléchargeables directement, d’autres accessibles uniquement après un achat en boutique. Pourquoi ce changement de politique ? Pourquoi cette différence de traitement entre les logiciels ?

Comme évoqué un peu plus tôt, Ryxéo est une équipe qui regroupe des développeurs, graphistes et pédagogues qui œuvrent à l’essor et au maintien de la solution AbulÉdu. Les salariés de l’entreprise reçoivent un salaire à la fin du mois. Le modèle économique Ryxéo, tel un éditeur, est basé sur le support, la maintenance et les formations autour des solutions proposées à nos clients.

À côté de ça, il faut savoir que l’estimation des dépenses globales au niveau national en logiciels pour les écoles en 2011 est de plusieurs millions d’euros (exemple 500.000 euros pour l’académie de Toulouse, sources : http://tice.ac-toulouse.fr/web/635-cheque-ressources.php) … Ne serait il pas pertinent que les ressources libres en bénéficient ?

Il n’en demeure pas moins que, nous sommes tous très impliqués, individuellement comme collectivement, et ce depuis de nombreuses années, à titre bénévoles dans des associations et des communautés. .

Cela dit, j’avoue qu’un de mes rêves serait de lancer une opération “logiciel libre à prix libre”… Peut être encore trop tôt… Mais un jour viendra, je l’espère.

Pour moi la réussite d’un projet libre n’est pas tant qu’il soit utilisé par des milliers d’utilisateurs que de créer des emplois et de la richesse. La FSF a eu l’intelligence de ne pas mettre de conditions « non commercial » dans la GPL et c’est vraiment important.

Puisque tu parles de “logiciel libre à prix libre”, RyXéo a lancé un Pedagogic Bundle permettant aux utilisateurs d’acheter un pack de logiciels du Terrier. SI je ne me trompe pas, cette opération en anglais a permis de récolter 800 $. Quel bilan en tires-tu ? Pourquoi ce choix d’une opération en anglais ?

C’est un test à plusieurs niveaux: je pense que l’aspect international est compliqué à aborder pour des logiciels pédagogiques, je ne pense pas que les enseignements soient les mêmes partout. Néanmoins je cherche pour voir s’il existerait un « écho » dans la communauté internationale qui gravite autour des logiciels libres et de l’éducation.

800€ c’est très peu et beaucoup : très peu compte tenu de l’exemple qu’on a pris pour s’en inspirer (humble bundle) et beaucoup parce que vu le peu de publicité qu’on a faite on a tout de même des retours.

Ensuite ce sont des personnes plutôt militantes qui nous ont pris ce bundle et nous ont spontanément proposé de participer aux traductions et prochaines offres…

Où en est le projet de micro-blogue pour les écoles primaires porté par l’association AbulÉdu-fr ?

Il s’agit d’un projet porté par l’association. Un projet véritablement important, à faire vivre, demandant du temps. Je profite donc de la tribune offerte pour demander à tout contributeur potentiel de ne pas hésiter à proposer son temps et son aide en remplissant ce formulaire de contact : http://www.abuledu-fr.org/Contacter-l-association.html

Passons à l’actualité chaude de RyXéo. Tu viens, ce samedi de présenter un produit qui devrait faire beaucoup de bruit, la TEDI. C’est quoi ?

Depuis deux ans, le phénomène « tablettes » envahit notre quotidien. Les écoles ne sont pas en reste et certaines, se sont lancées très tôt dans les démarches d’acquisition de ces nouveaux matériels.

La tablette est vue comme un gros téléphone, multi-tâche, à la frontière entre le matériel de productivité et le gadget. À ce titre je me dis que le combat de “détaxe” ou de “vente liée” est perdu ou tout au moins mal embarqué sur ces plates-formes …

Android prend de plus en plus de part de marchés et souffle le chaud et le froid (libre, pas libre, par exemple une version d’Android n’a jamais été publiée) … je fais de la veille technologique active et envisage un éventuel avenir libre aux tablettes scolaires.

RyXéo achète quelques tablettes pour découvrir que l’univers ARM (les puces qui équipent l’écrasante majorité des tablettes pour ne pas dire la totalité) est structuré d’une manière bien différente de la plateforme “pc/intel” que je connais bien. Il est par exemple très compliqué de choisir le périphérique d’amorçage et d’envisager de démarrer sur une clé usb, le réseau ou une carte SD … allons-nous être obligés de développer pour iOS ou Android ?

RyXéo développe cependant une « solution tablettes pour développeurs » sur une plate-forme intel tout en synthétisant notre cahier des charges « école primaire »  :

• Matériel aussi ouvert que possible
• Système d’exploitation libre et logiciels libres
• Assez robuste pour être confié à des enfants
• Léger
• d’un look “sympa” ou tout au moins, sortant de l’ordinaire

J’estime qu’en tant que développeurs nous avons des responsabilités. Je m’explique: si je développe une application pour iOS ou Android je ne peux pas ignorer que l’identité numérique des futurs utilisateurs de mon logiciel sera gérée par un de ces deux géants. Il en va de même pour les données qui seront forcément indexées voire stockées sur le cloud de ces mastodontes, probablement hors du territoire national et donc soumis à une loi qui n’est même pas la nôtre. De ce fait il est de notre responsabilité de proposer des alternatives durables, ouvertes, libres et pérennes. D’autant plus qu’on est dans un domaine ou nos utilisateurs (les enfants) n’ont pas encore construit leur esprit critique et qu’ils font confiance aux adultes que nous sommes pour avoir fait les bons choix !

Comment est né ce partenariat avec Unowhy ?

Après quelques recherches et échanges avec nos clients et partenaires, la tablette qooq/unowhy est identifiée. Contact est pris avec l’industriel, nous achetons une tablette « développeur » et installons un hack d’AbulÉdu en test.

Ensuite tout s’enchaîne, nous rencontrons l’équipe dirigeante de Unowhy, effectuons une démonstration de la tablette « AbulÉdu », et nous voici, samedi 8 décembre 2012, pour l’annonce officielle de cette Tablette.

J’apprécie en particulier sur leur tablette et avec leur approche qu’il n’y a ait aucun connecteur propriétaire: rien que du standard ! (usb, ethernet, sdcard, jack pour le casque) … c’est suffisamment rare pour le signaler !

Présent à Éducatice Unowhy présentait justement son projet de tablette scolaire et parlait d’une expérimentation en collège. Est-ce un projet différent ou bien est-ce également un partenariat avec RyXéo ?

Ce sont deux projets différents qui pourraient paraître complémentaires. Je précise néanmoins que TEDI AbulÉdu a aussi été présentée le 22 sur le stand de Unowhy à Éducatice.

Je ne savais pas. Je n’ai pas eu l’occasion d’aller à Éducatice cette année.

Au niveau du système d’exploitation, je suppose que ce n’est pas iOS. Est-ce Android ou un développement maison ? Une adaptation d’AbulÉdu ?

C’est un vrai GNU/Linux, fondé sur l’excellent boulot de linaro. Et sur lequel nous avons réalisé le même travail que pour AbulÉdu « Live » ou « Serveur ».

Puisqu’on parle de partenariat, il y au final peu d’acteurs dans l’univers du libre au niveau de l’école primaire (ASRI Édu, Beneyluschool, OLPC, OOo4kids, Sankoré, GCompris …). As-tu des échanges, liens avec eux ?

C’est juste de le dire, on est peu nombreux et la quantité baisse avec les années (par exemple cette année nous perdons l’excellente équipe de PingOO). Le grand absent de cette liste est edubuntu, qui, pour moi, est un exemple intéressant : AbulÉdu serveur étant fondé sur ubuntu, j’ai souhaité leur offrir l’interface d’administration d’AbulÉdu il y a quelques années. Tous les paquets .deb existent et marchent dans plusieurs centaines d’école tous les jours en France … Le retour que j’ai eu a été … étonnant : notre interface d’administration étant en PHP le responsable du projet edubuntu n’a même pas daigné le regarder. Aujourd’hui nous faisons et refaisons tous la même chose (des interfaces d’administration) au lieu d’utiliser des forces à la création de ressources pédagogiques, de logiciels d’apprentissages, de retours utilisateurs etc.

Beneyluschool est exemple également intéressant. En 2010 quand on a voulu proposer un ENT à nos clients, on a cherché les sources de la Beneyluschool… introuvables ou alors une version vieille comme Hérode. D’autre part, le site faisant appel à du flash de manière importante, nous avons décidé de créer notre ENT. Cependant, en 2012, Beneyluschool libère le code de sa version 3.0 qui n’utilise à priori plus de flash… Je suis heureux de voir cette nouvelle orientation et le contact est en cours pour voir comment intégrer l’accès à l’ENT depuis les tablettes pour les clients que nous avons en commun.

De même, nous avons intégré OOo4Kids dans AbulÉdu mais quelques ajustements sont encore nécessaires, notamment entre OOo et OOo4Kids (quel logiciel a la priorité sur l’association des fichiers dans le navigateur de fichiers par exemple).

Concernant GCompris la cible et l’approche sont différentes : GCompris est un moteur d’activités ludo-éducatives, Bruno a même ajouté l’interprétation de script python dans GCompris pour simplifier l’ajout de nouveaux modules par des développeurs tiers. Notre approche est différente : nous avons préféré avoir un exécutable indépendant pour chaque logiciel. Par contre au niveau de la distribution AbulÉdu, GCompris fait partie des logiciels que nous diffusons systématiquement.

Avec OLPC et ASRI Édu, nous n’avons pas encore de réels liens mais l’occasion se présentera peut être un jour.

Ryxeo fêtera ses 10 ans l’année prochaine, c’est un véritable succès ! Si tu devais choisir parmi ces propositions laquelle définirait le mieux la situation actuelle ?

* Grâce au choix du logiciel libre, RyXéo est prospère et je suis un patron très riche. * L’équilibre est précaire mais sans le logiciel libre l’aventure n’aurait pas été possible. * RyXéo aurait sûrement été plus prospère en choisissant le logiciel privatif.

À vrai dire, je ne sais pas trop commenter ces aspects. Je dirais que depuis 10 ans, l’aventure est belle, soumise à des moments heureux comme des périodes délicates. Si je devais tirer un bilan, il serait très positif. La prospérité est plus celle du cœur et de la connaissance que du compte en banque mais je ne regrette pas mes choix !

Pour finir, si des lecteurs du blog sont intéressés par un des projets, peux-tu nous dire de quoi vous avez besoin actuellement ?

Le projet AbulÉdu recherche des contributeurs pour collecter des ressources libres sur internet et les ajouter dans l’entrepôt de données data.abuledu.org En trois mois nous avons déjà collecté plus de 5000 ressources libres… aidez-nous pour arriver à 50 000 pour les RMLL 2013 !

Ensuite si nous voulons que notre plate-forme soit remplie de ressources libres, il faut les produire. Nous lançons donc un appel à tous les enseignants créateurs de ressources à les mettre sous licence libre (compatible avec cc-by-sa) et nous les envoyer (ou les envoyer eux même sur l’entrepôt) pour qu’elles soient mises à disposition de tous et indexées selon les normes en vigueur, (LOM, SCOLOM etc.) dans l’entrepôt de données pédagogiques .

Enfin, nous sommes à la recherche de donneurs de voix pour enregistrer des histoires pour les enfants, ou lire des textes.

Sur les aspects techniques, si des développeurs souhaitent rejoindre la communauté AbulÉdu, ils et elles seront chaleureusement accueillis (voir la liste de diffusion dev@abuledu.org) et notamment lors de nos week-ends abuledu@ryxeo.

Merci Éric !

Des kids, du code et du cake…

Le 29 septembre dernier je me suis rendu avec Adrienne Alix (Wikimédia France), Frédéric Couchet (April, de dos sur la première photo) et nos enfants respectifs à un « Coding Goûter » parisien.

Jugeant l’expérience tout à fait intéressante, et ma fille aussi (au tableau sur la seconde photo, présentant son travail sur Scratch), j’ai proposé aux organisateurs Julien Dorra, Jonathan Perret et Raphaël Pierquin un entretien pour en savoir plus et donner éventuellement envie d’essaimer.

Bonjour, pouvez-vous vous présenter succinctement ?

Julien : J’anime des communautés techno-créatives 🙂 C’est à dire que je crée les bonnes conditions pour que des personnes d’horizons différents créent avec les technologies d’aujourd’hui. Dans des universités, pour des institutions, et bien sûr avec Dorkbot Paris, Museomix, ArtGame weekend… et Coding Goûter !

Jonathan et Raphaël : Nous sommes tous les deux papas et développeurs. Nous travaillons chez /ut7, une coopérative d’agilistes. Notre métier, c’est d’aider d’autres développeurs à travailler en équipe. Nous animons aussi des ateliers de co-apprentissage avec des enfants de plus de 25 ans : nos formations, mais aussi Dojo de Développement, Agile Open, Dojo Lean Startup, soirées Cambouis…

Alors un « Coding Goûter » c’est quoi ?

Raphaël : Un Coding Goûter, c’est un rendez-vous festif avec des gâteaux, où petits et grands apprennent à programmer, ensemble.

Julien : C’est aussi un moment pour partager le plaisir de créer des choses avec du code, et d’expérimenter. Et pour les adultes qui, comme moi, ont programmé quand ils étaient enfants mais ont ensuite arrêté d’écrire des programmes – c’est une manière de réveiller une pratique qui était passé au second plan. Il y a des peintres du dimanche, je me revendique comme codeur du dimanche !

Comment l’idée est-elle donc née ?

Julien : J’ai rencontré Jonathan lorsqu’il a participé au premier – et au second ! – ArtGame weekend. Après ça, on a beaucoup discuté de ce que pouvait signifier l’éducation au code, de l’impact des nouveaux outils, à quoi pouvait ressembler un jeu de programmation.

Jonathan : Je cherchais à partager avec mes filles mon métier de développeur, mon plaisir d’écrire des programmes. J’étais frustré de ne pas trouver les moments « à la maison ». D’où l’idée d’un goûter avec des enfants, où l’on programmerait.

Julien : J’ai lancé de mon côté une petite enquête pour mieux comprendre ce que les parents (non tech inclus) pensaient du sujet. Les dizaines de réactions extrêmement diverses nous ont assez étonnés. Cela allait de l’évidence, au dégoût de l’idée même d’apprendre aux enfants à programmer !

Jonathan : Finalement, un matin de décembre 2011, j’ai réalisé que nous avions déjà toutes les cartes en main. Il suffisait de choisir une date, lancer des invitations et ouvrir les bureaux de /ut7 un samedi après-midi.

Raphaël : Quand Jonathan a évoqué son idée, j’étais enthousiaste. Ma motivation première, était de montrer à mes enfants ce qu’était mon métier. Après plusieurs séances, ce qui persiste, c’est le même plaisir que celui de jouer aux LEGO avec mon fils : s’amuser en construisant des choses ensemble.

Vous en êtes désormais à huit Coding Goûters, quel retour d’expérience en faites-vous ? Qu’est-ce qui a bien fonctionné ? Qu’est-ce qui peut être amélioré ?

Julien : On sait qu’il ne faut pas trop d’enfants, 12 c’est bien. On sait aussi que à la maison, ça marche moins bien, on est pas assez hors-contexte. Il y a plein de sollicitations, y compris pour les grands !

Raphaël : Une leçon essentielle que j’ai apprise : quand il s’agit d’apprendre, les adultes sont des enfants comme les autres. Une autre encore : c’est important de ponctuer les goûters avec des pauses où l’on prend le temps de célébrer les réalisations des participants. Une piste d’amélioration : publier un petit manuel pour aider de potentiels organisateurs de Coding Goûters à se lancer.

Est-ce facile de gérer en même temps différentes classes d’âge (quant on sait par exemple les écarts qu’il peut y avoir entre un enfant de 6 ans et de 12 ans) ?

Julien : Cela ne se pose pas dans ces termes. On vient avec nos enfants. Chacun fait.

Raphaël : Nous utilisons le même principe que dans les formations pour adultes de /ut7 : une grande variété d’activités, et la liberté pour chacun de choisir ce dont il a besoin pour apprendre. Ça marche très bien, encore mieux qu’avec des groupes sans enfant.

Julien : Séparer les classes d’âge peut sembler plus facile, mais c’est une homogénéité fictive. Les enfants d’un même âge n’ont ni le même niveau, ni les mêmes envies. Par exemple un enfant de 10 ans avait envie de créer des applications iPad, ce qui l’a motivé pendant tout un goûter pour explorer Xcode et Objective-C. Un grand de 14 ans pendant ce temps-là faisait du RoboZZle.

Plutôt que des séances « one shot » envisagez-vous d’organiser à terme des « Coding Goûter » plus réguliers tout au long de l’année avec le même groupe d’enfants-parents ? Et de ce fait pouvoir alors proposer quelque chose de plus structuré et progressif ?

Julien : Ce ne sont déjà plus des séances uniques, puisque nous avons organisé près d’un Coding Goûter par mois tout au long de 2012. Selon leurs disponibilités, les enfants et les adultes reviennent d’un goûter à l’autre. Mais derrière cette régularité, il n’y a pas de volonté de structurer l’apprentissage, ni d’introduire de la progressivité. C’est un moment d’exploration, de découverte. Le but n’est pas d’enseigner. Le but n’est pas l’acquisition de compétence en soi. De la même manière que l’on ne fait pas faire du dessin aux enfants pour qu’ils acquièrent une compétence technique précise.

Raphaël : Pour moi, le Coding Goûter est avant tout un loisir créatif, famillial et social. De fait, les familles qui participent, ponctuellement ou régulièrement forment une communauté qui crée une continuité entre chaque séance. Néanmoins, nous ne suivons pas de plan d’une séance sur l’autre, et ce n’est pas prévu.
Je me lancerai peut-être un jour dans la construction d’un programme structuré, mais ça sera en plus du Coding Goûter.

Ne pensez-vous pas que les « Coding Goûter » viennent combler une lacune, un vide de l’Education nationale ? Un déficit aussi bien dans le fond (inviter à coder, à créer) que dans la forme (le dispositif pédagogique assez novateur que vous proposez). A moins que vous jugiez que tout va bien et que chacun est à sa place ?

Raphaël : La pauvreté du programme informatique de l’école m’attriste, et le potentiel de progression est énorme. Attention néanmoins : la recette des Coding Goûters n’est pas nécessairement adaptée au contexte de l’école.

Jonathan : Je regrette également de voir que l’école ne donne plus aux enfants l’occasion de découvrir la magie de la programmation, comme nous en avons eu la chance à l’époque du plan « Informatique pour tous », mais elle ne peut peut-être pas tout faire non plus…

Julien : Au cours des prochaines années, on va à nouveau beaucoup entendre parler de l’enseignement de la programmation. La discussion est actuellement très active au Royaume-Uni, cela va revenir en France.
Et tu peux être sûr que cela sera principalement axé sur le « besoin de développeurs pour l’économie numérique ». On n’est pas du tout sur cet axe. On a envie que nos enfants programment, et oui, c’est vrai qu’ils ne le font pas à l’école et c’est dommage – car ils vont passer beaucoup de temps à l’école. Mais on ne cherche pas à fournir des développeurs aux SSII françaises dans 15 ans ! Probablement même le contraire 🙂
Est-ce qu’on comble un manque ? Avant tout, on comble un manque… pour nous et nos enfants ! Puis les enfants de nos amis, de nos collègues 😉
D’une certaine manière, on a été obligés de reconnaître qu’on répondait à un besoin fort, car nous avons des emails réguliers de parents qui veulent en organiser dans leur ville, ou être avertis du prochain goûter. À peine visibles, nous étions déjà sollicités.
Est-ce qu’on peut-être une part de la réponse aux difficultés de l’école de s’ouvrir aux changements sociaux en cours ? Pour l’instant non : on est en parallèle du système scolaire, et nous n’avons aucun lien avec les instances scolaires.

Si je vous dis que les « Coding Goûter » c’est quand même encore un « truc de bobos », vous pensez que c’est juste un gros troll ou bien une remarque valide ?

Raphaël : Quand j’avais 8 ans, dans ma campagne, il y avait un « club informatique » (MO5 rul3z !). C’était comme un Coding Goûter, mais sans les gâteaux. Ça me passionnait, je n’étais pas le seul, et personne ne s’en étonnait. On ne connaissait pas encore le mot « bobo », ni le mot « troll », d’ailleurs. Cela dit, oui, je suis bobo, et troll-proof, aussi.

Jonathan : La contrainte que nous avons mise pour l’accès au Coding Goûter, à savoir le fait de faire participer parents et enfants ensemble, crée probablement une barrière pour certaines familles où tout simplement les activités partagées ne sont pas la norme. Je ne peux qu’espérer que d’autres formats existeront pour donner à chaque enfant une chance de découvrir la programmation.

Julien : Coding Goûter est issu de parents qui apprécient la culture du code, et qui ont envie de la partager avec leur enfants. Il y a eu des réactions vaguement négatives. La ligne de partage ne semble pas être le niveau d’études, le niveau d’intellectualisme ou le revenu, mais plus la vision de la technologie comme quelque chose de positif, créatif, avec un empowerment possible ou comme un aspect négatif et enfermant de la vie contemporaine.
À ma connaissance, il y a des enfants de tout milieu qui ont envie de coder.
À l’opposé, il y a des parents de milieux aisés qui n’ont aucune motivation pour encourager leurs enfants à programmer, et même au contraire, y sont hostiles.
Maintenant, si la vraie question est « quelle diversité pour les Coding Goûter ? » on peut noter que nous avons déjà une parité fille-garçon des enfants qui est unique pour des sessions de programmation mixte (en fait, on a même toujours eu plus de filles que de garçons…).
C’est un bon signe. Il y a un effet de réseau sur les parents, c’est certain, tout simplement car on est un tout petit groupe qui grandit de proche en proche. Mais du coup, il y a peu de pression de sélection sur les enfants.

Plus concrètement, quels sont, dans le détail, les logiciels que vous proposez ? Quels sont leurs spécificités ? Pourquoi les avoir choisis ?

Julien : On a testé beaucoup de choses, et on continue de tester des nouveaux outils. Il y a des choses incroyables qui se passent du côté des outils web, dans le navigateur. J’ai adoré faire du LiveCodeLab avec des ados, en particulier.
Mais les grands classiques comme Scratch sont toujours aussi intéressants.
Le choix se fait sur la facilité de prise en main, le niveau des enfants (et des adultes !), le but (si un enfant veut faire un jeu sur tablette, on va l’orienter vers GameSalad, par exemple), et les découvertes du moment.

Raphaël : Pour les logiciels : à chaque séance, on en essaye de nouveaux, et on garde ceux qui nous plaisent.
Je choisis les logiciels en fonction du ou des participants qui programment avec moi, par exemple avec un enfant qui ne sait pas encore lire, ou avec un ingénieur, j’aime bien commencer avec RoboZZle, tandis qu’avec des enfants de 5 à 7 ans, on se raconte une histoire, et on construit un jeu petit à petit sur Scratch. Même si ils ne conçoivent qu’une petite partie de l’algo, le plaisir d’avoir créé est bien là ! En général, on arrête de programmer quand ça devient plus amusant de jouer que de créer le jeu.
Scratch est aussi idéal pour la tranche d’âge intermédiaire : souvent, des groupes de deux ou trois enfants de 8 à 50 ans se forment. Ils suffit de les mettre sur la voie, et ils parviennent à créer des programmes, en s’appuyant sur les participants les plus expérimentés (pas nécessairement les plus âgés). Et avec des garçons pré-ados, on a tenté de construire un circuit logique dans un univers virtuel (Minecraft). Pas facile de faire collaborer tous ces avatars !

Comprenez-vous ceux qui (comme nous) souhaitent que les logiciels proposés soient « le plus libre possible » ?

Raphaël : Oui. Et d’ailleurs, goûter au plaisir d’utiliser du code que l’on a écrit soi-même, c’est faire un premier pas dans les traces qui mènent au logiciel libre, non ?

Jonathan : Je trouve cela assez sain. Au quotidien, je n’utilise pas que des logiciels libres, mais quand j’en ai l’occasion j’essaie d’expliquer à mes enfants ce qu’est un logiciel libre afin qu’elles puissent plus tard faire des choix informés.

Julien : Le logiciel libre fonctionne évidemment en harmonie avec les pratiques d’appropriations collectives.
Il y a des raisons idéologiques à ça, mais il y a aussi des raisons pratiques. Un exemple très concret : les enfants français ont besoin que les interfaces, la documentation, les exemples, soient traduits en français. Un outil libre est traduisible dès que la communauté le veut.
Par exemple, j’ai pris l’initiative de traduire LiveCodeLab, les tutoriaux en particulier, car je trouvais que c’était un outil fascinant, et je voulais voir comment les enfants et les ados allaient l’utiliser. Un code ouvert et un développeur amical, et cela a pris quelques heures !
Cela dit, j’aime les contradictions. Tester tous les outils, c’est se confronter, et confronter les enfants les plus grands, aux choix de leurs outils, aux système parfaits mais propriétaires et verticaux, aux possibilités des outils ouverts d’être modifiés, aux rythme d’évolutions des outils qui ne sont pas les mêmes.
De fait, des outils payants et fermés auront bien sûr bien moins de succès dans le contexte des Coding Goûters que des outils libres. La partie grise ce sont les outils propriétaires gratuits ou freemium très bien réalisés, comme GameSalad, qui ont une position unique et intéressante. On aime GameSalad comme on aime Photoshop, ou Google Docs. Un bel outil logiciel reste un bel outil logiciel.

Est-ce que vous avez déposé le nom et le concept de « Coding Goûter » ? Comme j’imagine que non, cela signifie que tout le monde peut en organiser ! Vous connaissant un peu, j’imagine même que c’est quelque chose que vous encouragez. Quels conseils donneriez-vous donc, comment vous contacter et trouver trace des « Coding Goûter » précédents ?

Jonathan : Pas de marque déposée effectivement. L’idéal serait au contraire que le mot devienne aussi banal que « week-end » ou « pique-nique » !

Julien : On encourage tout le monde à organiser des Coding Goûters, bien sûr !
On imagine que dans quelques temps, il y aura des Coding Goûter un peu partout en France, et ailleurs, et que nos enfants pourront y participer où qu’ils soient, se faire de nouvelles copines et de nouveaux copains.
Ce qui ne doit pas arriver, c’est de laisser le concept être avalé par les habitudes antérieures, et devenir trop scolaire ou trop orienté-animateur et donc moins exploratoire et moins dirigé par les désirs créatifs des enfants.
Si vous participez avec vos enfants à un Coding Goûter, vous savez que ça ne sera pas un cours ou un tutoriel, que vous pourrez rester avec vos enfants, qu’il y aura des démo-spectacles par les enfants – et des gâteaux ! Ce sont tous ces petits détails qui comptent pour nous.
Le format est encore en évolution, on teste des choses – mais on tient énormément à l’esprit.

Un dernier mot, un prochain rendez-vous ?

Julien : Il y a des Coding Goûter presque tous les mois. Pour être averti du prochain, il suffit d’envoyer un message à contact AT codinggouter.org, ou de fréquenter notre groupe Facebook.

Raphaël : A ceux qui voudraient organiser leur Coding Goûter : lancez-vous ! Si vous ne savez pas comment vous y prendre, venez nous voir, ou mieux : demandez de l’aide à vos enfants.

La loi de Moore (qui n’est en fait qu’un conjecture) affirme que le nombre de transistors des microprocesseurs sur une puce de silicium double tous les deux ans. Ce qui, par extension, a donné pour le grand public que le rapport entre la puissance d’un ordinateur et son prix double tous les dix-huit mois.

Autrement dit, les machines sont de plus en plus puissantes et de moins en moins chères.

C’est bien ce qu’il s’est produit et se produit encore, pour le plus grand bonheur du logiciel libre et sa culture…

Un allié secret de l’open source : la loi de Moore

Open source’s secret ally: Moore’s Law

Glyn Moody – 10 octobre 2012 – The H
(Traduction : KoS, ProgVal, Sylvain, greygjhart)

Linux est passé du statut de petit bidouillage sympa dans une chambre à celui de logiciel capable de changer le monde il y a un peu plus de 21 ans lorsque Linus a envoyé son fameux message : « Bonjour aux utilisateurs de minix », invitant les gens à le rejoindre. Comme je l’ai remarqué le mois dernier, cette approche ouverte, collaborative était tout à fait nouvelle et s’est avérée décisive dans l’adoption et le développement de Linux.

Cela fut possible car Internet était déjà suffisamment présent pour qu’assez de gens se joignent à l’équipe de volontaires de Linus en faisant jouer à plein l’intelligence distribuée. En d’autres termes, l’émergence du logiciel libre est intimement liée à internet. En effet, le décollage rapide de Linux, comparé aux progrès plutôt lents du projet GNU est probablement dû, au moins en partie, au fait que ce dernier ne pouvait se reposer sur une connectivité globale. C’est grâce à cela que Richard Stallman a pu vivre des ventes de GNU Emacs, qu’il distribuait sur des bandes magnétiques.

La nature symbiotique du logiciel libre et d’internet, le premier utilisant le second, le second étant utilisé par le premier, est maintenant largement reconnue. Mais un autre facteur clé dans l’apparition de l’open source a été sous-estimé, alors que Linus lui-même le mentionne dans ce fameux premier message :

Je programme un système d’exploitation (gratuit, c’est juste un passe-temps, ça ne sera pas un gros projet professionnel comme GNU) pour des clones AT 386(486).

Comme nous vivons à l’ère Intel depuis deux décennies, une ère qui touche peut-être à sa fin, avec la montée en puissance des smartphones et des tablettes et leurs processeurs de familles différentes, il est facile de négliger l’importance du fait que Linus développa Linux pour les processeurs 80386.

Aussi étrange que cela puisse paraître , l’ordinateur principal de Linus avant qu’il n’écrive Linux était un Sinclair QL, un ordinateur typiquement anglais qui utilisait le processeur Motorola 68008 (qui fonctionnait à 7,5 MHz), fourni avec 128K de RAM et utilisait un infâme microdrive comme stockage.

Passer à un PC 386, fonctionnant à 33MHz, avec 8 Mo de RAM et 40Mo de disque dur, était un véritable bond en avant pour Linus, et poussa ses finances à leurs limites. En fait, il n’a pu acheter son premier PC que le 5 janvier 1991 parce qu’il reçut de l’argent pour Noël qu’il ajouta à un prêt étudiant que le gouvernement Finlandais lui avait récemment accordé. Ce dernier était censé payer sa nourriture et son logement pendant qu’il étudiait à l’université d’Helsinki mais comme il vivait toujours avec sa mère pendant cette période, il réussi à le détourner pour un usage plus intéressant.

Le fait qu’il puisse se payer un système aussi performant reposait sur l’amélioration continuelle du matériel, couplée à la diminution régulière des prix. C’est à dire que c’est grâce à la loi de Moore, qui dit que le ratio entre performances et prix double tous les 18 mois environ, que Linus a pu se retrouver avec le système 386 qu’il mentionne dans le premier message sur Linux.

Sans la loi de Moore, il serait sans doute resté avec son Sinclair QL, codant pour un système dont peu de gens se souciaient. Avec le 386, il a pu rentrer dans le courant dominant de l’informatique en même temps que de nombreuses autres personnes. Partout dans le monde (ou en tout cas dans les zones les plus riches) les jeunes gens ont pu s’acheter de vrais ordinateurs basés sur l’Intel 80386 et (plus tard) 80486. Cela signifiait qu’ils pouvaient faire tourner le code de Linux dès ses débuts, et aussi qu’ils pouvaient contribuer.

Encore une fois, sans la loi de Moore mettant des ordinateurs moins chers dans les mains de bidouilleurs, Linus n’aurait pas été en mesure de construire cette communauté mondiale à travers Internet et le rythme de développement en aurait souffert. En effet, comme la loi de Moore continuait de tirer les prix vers le bas tout en augmentant les performances, de plus en plus de gens dans un nombre croissant de pays ont pu acquérir des PCs suffisamment puissants pour rejoindre le projet Linux. Des processeurs plus rapides signifiaient des temps de compilation plus courts pour les programmes ce qui rendait le bidouillage du code plus facile – et plus agréable.

Il y a ici un contraste intéressant avec le développement du logiciel propriétaire. Les avancées dues à la loi de Moore ne profitent que peu aux programmeurs dans les entreprises, puisqu’ils ont généralement du matériel assez bon. Et les entreprises n’en bénéficient guère plus, puisque ce qui coûte le plus dans la programmation est le salaire des programmeurs, pas le prix de leurs PCs. Dans le monde du logiciel libre, les programmeurs volontaires sont bénévoles et le facteur limitant est le prix du matériel. C’est pourquoi la loi de Moore est très avantageuse pour l’open source.

Potentiel futur

Ce n’est pas un effet purement historique des premières heures de Linux. Nous voyons encore aujourd’hui la Loi de Moore tirer les prix vers le bas en accueillant toujours plus d’utilisateurs. Un bon exemple est le mini-ordinateur Raspberry Pi. Il offre les bases de la puissance d’un PC sur une petite carte mère, à un prix minuscule. Cela signifie que non seulement les personnes ordinaires – même des enfants – peuvent l’acheter sans avoir à penser au prix, mais aussi que les écoles peuvent envisager d’en acheter un pour chaque étudiant, ce qui est normalement inenvisageable avec les prix prohibitifs des PC, même ceux bon marché.

L’effet que le Raspberry Pi aura sur l’éducation n’est pas encore clair, mais il semble que celui-ci ou l’un des nombreux systèmes semblables à prix très bas va permettre l’arrivée de nouveaux types de projets avec des nouveaux groupes de contributeurs, dans les pays émergents par exemple.

Et les choses sont déjà en train d’aller plus loin. Voici un projet Kickstarter qui illustre à merveille cette progression continue rendue possible grâce à la loi de Moore. Il s’agit de Parallella. l se décrit comme un « Supercalculateur Grand Public », et ce n’est pas une blague.

Une fois terminé, l’ordinateur Parallella devrait fournir l’équivalent d’un processeur à plus de 45Ghz sur un circuit de la taille d’une carte de crédit tout en consommant moins de 5 Watts en fonctionnement normal. En s’en tenant seulement à la fréquence, c’est plus de puissance qu’un serveur haut de gamme qui coûte des milliers de dollars et consomme 400W.

Important, tout le système sera ouvert :

• Accès ouvert : absolument aucun accord de non divulgation ou accès spéciaux nécessaires ! Toute l’architecture et le kit de développement seront publiés sur le web dès que le projet sera financé sur Kickstarter.
• Open Source: la plateforme Parallella sera basée sur des outils et des bibliothèques libres et gratuites. Tous les fichiers de conception des circuits seront fournis une fois que Parallella sera sur le marché
• Bon marché : les coûts du matériel et des outils de développement ont toujours été une barrière très difficile à franchir pour les développeurs cherchant à écrire des applications haute-performance. Notre but est de fournir l’ordinateur haute-performance Parallella à un coût inférieur à 100$, le rendant accessible à tous.

Oui, c’est un super ordinateur à 45GHz, fourni en standard avec Ubuntu, pour moins de 100$. Si Parallella parvient à sortir cela – et en tant que projet Kickstarter (il y a toujours le risque qu’il ne soit pas totalement financé ou qu’il ne fonctionne pas correctement) il va mettre un nouveau niveau de puissance de calcul entre les mains de tout le monde, y compris les étudiants.

Potentiellement, cela va permettre à des gens qui, jusqu’à présent, ne pouvaient tout simplement pas s’acheter une telle puissance de calcul de démarrer une toute nouvelle génération de projets open source. Encore une fois, le principal bénéficiaire ici est l’open source : si une entreprise a besoin d’un supercalculateur, elle va généralement l’acheter immédiatement, puisqu’elle peut se permettre de payer un prix conséquent pour les modèles actuels. Ce que Parallella apporte, grâce à la loi de Moore, est la démocratisation d’une puissance de calcul de cet ordre, qui ne va plus être réservée à des projets commerciaux disposant de solides fonds.

Il est important de noter que c’est la loi de Moore, agissant sur le matériel qui apporte ces bénéfices, plutôt que n’importe quel changement exponentiel dans le logiciel (qui n’y contribue qu’indirectement). De plus des lois de Moore pour d’autres types de matériel commencent également à prendre forme. Un exemple frappant en est l’impression 3D, où les prix baissent régulièrement. Ou encore le monde du séquençage du génome, démêler les milliards de « lettres » chimiques qui forment la double hélice de l’ADN, qui voit l’arrivée de changements encore plus importants.

Vous savez peut-être que le coût de séquençage du génome baisse mais vous n’avez peut-être pas la moindre idée de la vitesse à laquelle il baisse. Le National Human Genome Research Institute qui fait partie du National Institute of Health américain a compilé des données étendues sur le coût de séquençage de l’ADN au cours de la dernière décennie et a utilisé ces informations pour créer deux graphique à couper le souffle. Les chercheurs du NHGRI montrent que non seulement les coûts de séquençage sont en chute libre mais ils dépassent la courbe exponentielle de la loi de Moore d’une grande marge.

Cela signifie que le coût de séquençage de votre génome, ou de n’importe quel autre organisme, va bientôt devenir à la portée de tout le monde. Cela va-t-il créer une communauté globale de bio-hackers libristes, menée par un nouveau Linus avec un séquenceur de bureau (et peut-être un supercalculateur Parallella) dans sa chambre à coucher ? L’expérience des logiciels libres suggère que oui et nous apprend que nous ne devrions jamais sous-estimer le simple pouvoir de la loi de Moore à conduire des changement inattendus et révolutionnaires.

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

On l’appelle sysadmin, adminsys ou plus correctement administrateur systèmes. Il a la lourde charge de s’occuper des serveurs d’une organisation.

Si vous avez l’impression qu’il bulle toute la journée, ne le critiquez pas ! Vous êtes en réalité en face d’un excellent administrateur systèmes 🙂

12 raisons pour lesquelles tous les administrateurs système devraient être paresseux

12 Reasons Why Every Linux System Administrator Should be Lazy

Ramesh Natarajan – 12 juillet 2011 – GeekStuff.com
(Traduction : Husi10, Ag3m, Gatitac, Kathryl, Thur, M0tty, Ag3m, Dominique, minimoy)

Un administrateur systèmes fainéant est un bon administrateur systèmes
— Anonyme

Le travail d’un administrateur systèmes n’est généralement pas visible des autres services informatiques ou par les utilisateurs finaux. La plupart du temps, ils regardent les administrateurs systèmes en se demandant pourquoi ils n’ont pas l’air de faire grand chose.

Quand vous voyez un administrateur systèmes qui est tout le temps en train de courir dans tous les sens, à essayer d’éteindre le feu, en prise constante avec des problèmes de production, vous pourriez penser qu’il travaille dur et fait vraiment bien son boulot. Mais en réalité il ne fait pas bien son job.

Quand vous voyez un administrateur système (UNIX/Linux, base de données, réseau), qui apparemment n’a pas l’air de se fouler beaucoup au bureau, semble toujours relax et n’a pas l’air d’avoir une activité visible, vous pouvez être certain qu’il fait bien son job.

Voici 12 raisons qui font d’un administrateur systèmes paresseux le meilleur des administrateurs systèmes :

1. Qui est le chef ? La principale raison pour laquelle un administrateur systèmes paresseux est le meilleur administrateur système possible tient à son attitude. Ils ne voient pas tout à fait les machines comme les autres services informatiques. Il y a une différence entre les développeurs et les administrateurs systèmes. Les développeurs pensent qu’ils sont là pour servir les machines en écrivant du code. Il n’y a rien de mal dans cette démarche puisque les développeurs prennent beaucoup de plaisir à écrire du code. Mais les administrateurs systèmes pensent tout autrement. Ils pensent au contraire que les machines sont à leur service. Tout ce qu’ils ont à faire, c’est nourrir la machine, la rendre heureuse et laisser la machine faire tout le dur labeur pendant qu’ils se relaxent et paressent. La première étape pour devenir un administrateur systèmes paresseux demande parfois un léger changement d’attitude : il s’agit de faire savoir à la machine que vous êtes le patron.

2. Écrire des scripts pour des tâches récurrentes. Être fainéant, c’est être malin. Un administrateur systèmes intelligent est passé maître dans tous les langages de script (bash, awk, sed, etc.). Chaque fois qu’il sera obligé de faire une tâche, et s’il y a une vague possibilité qu’on puisse avoir besoin de ce même travail plus tard, il écrira un script pour faire le boulot. Ainsi, lorsqu’on lui demandera plus tard de refaire le même travail, il n’aura pas à réfléchir ; il aura simplement à exécuter le script puis à retourner paresser.

3. Tout sauvegarder. Être fainéant signifie tout sauvegarder. Un administrateur systèmes paresseux sait qu’il doit donner un peu de temps dans la création de processus de sauvegarde, et donc écrire des scripts de sauvegarde pour toutes les applications et tous les systèmes critiques. Quand l’espace disque n’est pas un problème, il planifie la sauvegarde pour toutes les applications même si elles ne sont pas critiques. Ainsi, dès que quelque chose se passe mal, il ne se met pas à transpirer de stress, il a simplement besoin de restaurer une sauvegarde pour pouvoir retourner aux trucs paisibles qu’il faisait juste avant.

4. Prévoir un plan de reprise d’activité. Les administrateurs systèmes n’aiment pas avoir à gesticuler dans tous les sens en cas d’urgence. Quand tout se passe bien, ils prennent un peu de temps pour créer un plan de reprise d’activité et de récupération de données.Comme ça, quand les choses tournent mal, ils peuvent le suivre, faire revenir rapidement les choses à la normale, puis retourner encore à leur rythme d’administrateur paresseux.

5. Configurer un sytème à haute redondance. Les administrateurs sysèmes fainéants n’aiment pas être réveillés au beau milieu de la nuit à cause d’une bête panne materielle. Ils font donc en sorte que les periphériques soient hautement redondants. Cela inclut à la fois le matériel et les logiciels : ils ont deux cartes réseaux configurées, une double alimentation, deux disques durs, bref tout en double. Comme ça, si l’un des équipements vient à flancher, le système fonctionnera toujours et notre fainéant d’administrateur pourra se concentrer à la réparation de l’équipement défaillant lorsqu’il se lèvera le matin, à la même heure que tous les autres matins.

6. Laisser de la place pour une croissance inattendue. Un administrateur systèmes paresseux ne permet jamais à son système de tourner à plein régime. Il garde toujours de la place libre en cas d’imprévus. Il s’assure que le système ait assez de CPU, ainsi que de l’espace disque et de la RAM disponibles. Lorsque le service commercial décide de larguer des tonnes de données pendant la nuit, il n’a pas besoin de réfléchir à la façon de gérer cette croissance inattendue.

7. Être proactif. Être paresseux ne veut pas dire que vous devez juste vous assoir et vous tourner les pouces. Être paresseux signifie être proactif. Les administrateurs systèmes paresseux détestent être réactifs. Ils anticipent toujours les difficultés et l’expansion. Lorsqu’ils ont du temps libre à disposition (et ils en ont donc beaucoup), ils gardent un œil attentif sur les projets afin de gérer la future croissance et éviter que des problèmes non prévus adviennent.

8. Adorer les raccourcis clavier. L’administrateur systèmes fainéants connaît tous les raccourcis clavier de toutes ses applications favorites. S’il passe quotidiennement un temps significatif sur une application, la première chose qu’il fait est de maîtriser les raccourcis clavier de cette application. Il tient à passer le moins de temps possible sur l’application pour parvenir à ses fins, et ainsi redevenir paresseux.

9. Passer maître de la ligne de commande. Tous les administrateurs systèmes paresseux sont des pros des lignes de commande. Cela s’applique aux administrateurs systèmes Linux, aux administrateurs de bases de données, aux administrateurs réseaux, etc. Si vous voyez un administrareur systèmes lancer une interface graphique alors que la même tâche peut être effectuée en ligne de commande, alors vous savez qu’il n’est pas un administrateur systèmes paresseux. Il y a deux raisons pour lesquelles les administrateurs systèmes paresseux adorent les lignes de commande. D’une, il peut faire les choses rapidement en ligne de commande. Et d’autre, ça lui donne l’impression que c’est lui le patron et non pas le système. Quand vous utilisez les lignes de commande, vous avez le contrôle, vous savez exactement ce que vous voulez faire. Quand vous utilisez une interface graphique, vous êtes à sa merci sans être sûr à 100% de ce qu’il va produire après votre clic.

10. Apprendre de ses erreurs. Les administrateurs systèmes fainéants n’aiment jamais faire les mêmes erreurs deux fois. Ils détestent travailler sur des problèmes imprévus, mais quand ils apparaissent, ils travaillent à le corriger, réfléchissent à comment cela est arrivé, et mettent immédiatement le nécessaire en place pour que cela n’arrive pas de nouveau. Travailler sur le même problème deux fois est considéré comme un véritable péché pour un administrateur système fainéant. Il aime travailler sur le problème une seule fois, faire ce qu’il faut pour prévenir l’apparition de la même erreur dans le futur, et retourner tranquillement paresser.

11. Se former en continu aux nouvelles technologies. Il n’y a rien de mal à apprendre de nouvelles technologies pour avoir un meilleur travail ou juste pour se tenir à jour des progrès dans le domaine. Mais un administrateur systèmes paresseux n’apprend pas de nouvelles technologies pour cette raison. Il s’y forme parce qu’il aime garder le contrôle sur les systèmes en permanence. Il sait que c’est lui le chef et non pas la machine. Ainsi, quand arrive une nouvelle technologie, il prend le temps de l’étudier. À présent, il a de nouveaux outils pour occuper le système tandis qu’il continue à paresser. C’est la paresse qui est la principale motivation de sa formation.

12. Tout documenter. C’est ce qui distingue les bons administrateurs systèmes des meilleurs administrateurs systèmes. Voyez-vous, l’administrateur systèmes paresseux déteste être dérangé lorsqu’il est sur la plage à profiter de ses vacances. Donc, que fait-il ? Il documente tout, de manière à ce que lorsqu’il n’est pas là, d’autres puissent faire le boulot de base à sa place, et fassent tourner les choses sans le déranger pendant ses vacances. Il y a une autre raison pour laquelle l’administrateur systèmes paresseux documente tout : parce qu’il oublie des choses. Comme il est fainéant, il a tendance à oublier ce qu’il a fait le mois précédent. Puisqu’il n’aime pas du tout réfléchir deux fois sur le même sujet, il documente tout, et quand il aura besoin de faire la même chose dans le futur, il reviendra à sa documentation pour comprendre ce qu’il avait fait la fois précédente.

Voilà. Être un administrateur systèmes fainéant, ce n’est pas si simple en fait, c’est même beaucoup de travail. Si vous n’en êtes pas, vous saurez désormais les reconnaître. Si vous en êtes et que vous courez toujours partout, vous savez maintenant ce qu’il vous reste à faire.

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