Dans les débats politiques au sujet du Web et du numérique en général, on parle souvent d’« algorithmes ». Il n’est peut-être pas inutile de revenir sur ce qu’est un algorithme et sur ce qu’il n’est pas. Si vous êtes informaticien·ne, vous savez déjà tout cela, mais, si ce n’est pas le cas, vous apprendrez peut-être ici une chose ou deux.

Par exemple, dans le numéro 3790 du magazine Télérama, en date du 3 septembre 2022, la directrice générale de YouTube, Susan Wojcicki, déclarait « Nous ne faisons pas d’éditorial au sens propre puisque tous nos contenus sont recommandés par des algorithmes ». Cette phrase est un condensé de mensonges, bien sûr. Wojcicki est bien placée pour savoir ce qu’est un algorithme mais elle essaie de faire croire qu’il s’agirait d’une sorte de processus magique et éthéré, flottant loin au-dessus des passions humaines, et n’agissant que pour notre bien.

Au contraire, un algorithme est une suite de décisions. Un algorithme, c’est un ensemble d’étapes qu’on va suivre pour un certain but. Choisir le but est déjà une décision. (Quel est le but des algorithmes de recommandation de YouTube ? Probablement de vous faire rester le plus longtemps possible, pour que vous avaliez davantage de publicité.) Mais choisir les étapes est aussi une décision. Rien dans le monde numérique ne se fait tout seul : des personnes ont décidé de l’algorithme. Que les recommandations de YouTube soient issues d’un humain qui vous observerait et déciderait, ou d’un programme automatique, dans les deux cas, c’est la décision de YouTube. Et il y a donc bien « éditorialisation ». YouTube n’est pas neutre. Même chose évidemment pour le moteur de recherche de la même entreprise, Google. Il classe les résultats en fonction de ce que Google a décidé, lors de l’écriture du programme. (Notez que c’est bien ce qu’on demande à un moteur de recherche : s’il trouvait 10 000 résultats et ne les classait pas, on serait bien ennuyé·e.)

On explique parfois l’algorithme en citant l’exemple d’une recette de cuisine : faites ceci, puis faites cela, ajouter ça, mettez le four à telle température. Mais les algorithmes ne sont pas juste une suite d’étapes, à effectuer quoiqu’il arrive. Ils incluent notamment ce qu’on nomme des tests, par exemple « si telle condition, alors faire ceci, sinon faire cela ». Un recette de cuisine qui contiendrait « si vous avez de la moutarde, ajoutez-en une cuillère » donne une meilleure idée de ce qu’est un algorithme.

Le mot d’algorithme vient d’Al-Khwârizmî (محمد بن موسى الخوارزمي), un mathématicien d’origine persane du 8e-9e siècle, qui travaillait à Bagdad (la Silicon Valley de l’époque, là où il fallait être pour travailler au plus haut niveau). Mais le concept d’algorithme existait bien avant lui. Vous avez peut-être appris à l’école l’algorithme d’Euclide pour trouver le PGCD (plus grand commun diviseur), algorithme conçu plus de dix siècles avant Al-Khwârizmî. Mais ce dernier a été le premier à décrire en détail l’idée d’algorithme et à proposer une classification des algorithmes.

Le principe de l’algorithme est donc très antérieur à l’ordinateur. Par exemple, une personne qui répond au téléphone pour une « hotline » a en général reçu des instructions extrêmement précises sur ce qu’il faut dire et pas dire, avec interdiction de s’en éloigner. Dans le monde des « hotlines », cela se nomme un script, mais c’est aussi un algorithme ; si le client dit ceci, répondre cela, etc. Remplacer les algorithmes par des humains pour les décisions, comme le préconisent certains, n’a donc pas de sens si ces humains appliquent strictement un script : ce sera toujours un algorithme.

Et à propos d’humains qui suivent un algorithme, comment se faisaient les calculs longs et complexes avant l’invention de l’ordinateur ? Il y avait des aides mécaniques (boulier, règle à calcul…) mais le gros du travail était fait par des humains. En français, autrefois, une « calculatrice » n’était pas un ordinateur mais une humaine qui passait sa journée à mouliner des chiffres. On pouvait avoir comme métier « calculatrice dans une compagnie d’assurances ». Même chose pour « computer » en anglais ; désignant aujourd’hui un ordinateur, il désignait autrefois un·e humain·e. Ce travail est bien montré dans le film « Les figures de l’ombre », de Theodore Melfi, qui se passe au moment où ces calculateurs humains sont peu à peu remplacés par des ordinateurs. (Le titre français du film fait perdre le double sens du mot « figures » en anglais, qui désigne un visage mais aussi un chiffre.)

Les programmes, eux, sont bien plus récents que les algorithmes. Ils sont également apparus avant l’invention de l’ordinateur, mais n’ont réellement décollé qu’une fois qu’on disposait d’une machine pour les exécuter automatiquement, et fidèlement. Un programme, c’est la forme concrète d’un algorithme. Écrit dans un langage de programmation, comme PHP, Java, Python ou Rust, le programme est plus précis que l’algorithme et ne laisse place à aucune ambiguïté : les ordinateurs ne prennent pas d’initiatives, tout doit être spécifié. La maternité de la programmation est souvent attribuée à Ada Lovelace au 19e siècle. Comme toujours dans l’histoire des sciences et des techniques, il n’y a évidement pas un·e inventeu·r·se unique, mais une longue chaîne de personnes qui ont petit à petit développé l’idée.

Le premier point important de cet article était qu’un algorithme, c’est une série de décisions (et la déclaration de Wojcicki au début, lorsqu’elle essaie de diminuer la responsabilité de YouTube, est donc ridicule). Un algorithme n’est pas un phénomène naturel mais la formalisation de décisions prises par des humains. Le fait qu’il soit programmé, puis exécuté par un ordinateur, n’exonère donc pas ces humains de leurs choix. (Et, je me répète, demander que les décisions soient prises « par des humains et pas par des algorithmes » n’a guère de sens : ce sont toujours des humains qui ont décidé, même quand leur décision passe via un algorithme.)

Le deuxième point qui me semble important est que tout système informatique (et je rappelle que l’engin plat qu’on met dans sa poche, et que le marketing nomme « smartphone », est un ordinateur) fonctionne avec des algorithmes. Le ministre de l’Intérieur Gérald Darmanin avait déclaré, à propos de la surveillance automatisée des citoyens, « De plus, alors que toutes les sociétés commerciales peuvent utiliser les données fournies par des algorithmes, seul l’État n’aurait pas le droit de le faire […] ? » et avait appelé à « pérenniser l’utilisation des algorithmes ». Par delà la question politique de fond, ces déclarations sont bien sûr absurdes. L’État utilise des algorithmes depuis longtemps, depuis qu’il utilise des ordinateurs. Mais il ne s’agit pas seulement de l’ignorance (et du mépris pour la technique) d’un ministre. L’utilisation du terme « algorithme » vise à faire croire qu’il s’agit de quelque chose de nouveau, afin de brouiller le débat sur les usages de l’informatique, et d’empêcher les citoyen·nes d’y participer utilement. La réalité, je le redis, est que cela fait longtemps qu’il existe des algorithmes et qu’ils sont utilisés.

Il y a par contre une nouveauté qui a pris de l’importance ces dernières années, ce sont les systèmes à apprentissage (parfois désignés par l’acronyme marketing IA – Intelligence Artificielle, qui ne veut rien dire) ou machine learning en anglais. Il existe de nombreux systèmes de ce genre, très variés. Mais le point commun est l’utilisation d’algorithmes qui évoluent sous l’influence des données qu’on leur donne. Pour prendre un exemple simpliste, on donne au programme des photos de chiens et de chats, lui indiquant à chaque fois s’il s’agit d’un chien ou d’un chat, et, après un grand nombre de photos, le programme aura « appris » et pourra classer correctement une nouvelle photo. Il y a beaucoup à dire sur ces systèmes à apprentissage mais, ici, je vais me contenter de faire remarquer qu’ils ne remettent pas en cause le pouvoir de décision. Au lieu de règles explicites dans un algorithme (« s’il a des griffes rétractiles, c’est un chat »), le système de décision est composé de l’algorithme qui apprend et des données qu’on lui soumet.

Il n’y a donc pas de changement fondamental : le système informatique qui prend la décision a toujours été conçu et entraîné par des humains, et ce sont leurs choix qui se refléteront dans les décisions. Ainsi, si on utilise un tel système pour traiter les CV dans un service de ressources humaines, si l’entreprise avait l’habitude de recruter préférentiellement des hommes, et si on entraîne l’algorithme avec les choix passés, il se mettra à privilégier les CV des hommes, pas parce qu’il serait « sexiste » (les algorithmes n’ont pas d’opinion ou de préjugés) mais parce que c’est ce que ses maîtres humains lui ont demandé, via les données qu’ils ont choisies.

Bref, chaque fois que vous entendrez quelqu’un éluder sa responsabilité en se cachant derrière « c’est l’algorithme », rappelez-lui qu’un algorithme, c’est un ensemble de décisions prises par des humains, et que ces humains sont responsables de ces décisions.

La gestion d’une communauté de développeurs d’un projet open source est assez délicate. Le langage de programmation Rust, conçu et développé de façon ouverte au sein de Mozilla depuis une bonne dizaine d’années, fait largement appel à sa communauté dans sa structure et son mode de développement.

Son originalité par rapport au management de projet en entreprise apparaît de façon intéressante dans le témoignage et les réflexions de Mara Bos, une jeune développeuse impliquée dans le projet dont Framalang a traduit ci-dessous les propos.

Article original sur le blog de l’autrice : Rust is not a company

Traduction Framalang : Fabrice, Côme, goofy

Rust n’est pas une entreprise

par Mara Bos

L’année dernière, en tant que contributrice occasionnelle au projet Rust, je n’ai pas trop réfléchi à la structure organisationnelle de l’équipe derrière le projet. J’ai vu une hiérarchie d’équipes et de groupes, de chefs d’équipe, etc. Tout comme n’importe quelle autre organisation. Cette année, après m’être davantage impliquée, et devenue membre de l’équipe Library ¹ puis cheffe d’équipe, j’ai pris le temps de me demander pourquoi nous avons cette structure et à quoi servent ces équipes.

Pas une entreprise

Dans la plupart des entreprises, on trouve des directeurs et des actionnaires et autres trucs dans le genre en haut de la hiérarchie, qui définissent les buts de l’entreprise. Objectifs, jalons, dates limites, et autres choses qui vont sûrement mener l’entreprise vers le but final quel qu’il soit ; généralement l’argent.

Ensuite il existe plusieurs niveaux de management répartis en départements et en équipes pour diviser la charge de travail. Chaque niveau prend en charge une part des objectifs et s’assure que sa part est faite, en assignant des tâches aux employés en bas de la hiérarchie, tous travaillant d’une manière ou d’une autre à atteindre l’objectif principal commun.

Alors que la structure derrière un gros projet open source comme Rust peut sembler similaire, vue de loin, c’est souvent complètement l’inverse. Dans un tel projet, les objectifs et buts ne sont pas ceux des équipes d’en haut, mais effectivement ceux des contributeurs.

En tant qu’équipe library, nous pourrions par exemple essayer de décider que le mécanisme de formatage (std::fmt) devrait être réécrit pour être plus petit et plus efficace. Mais prendre cette décision ne provoque pas la réécriture. Et nous n’avons pas d’employés à qui assigner les tâches. Ce n’est pas comme ça que ça fonctionne.

Au lieu de cela, un contributeur passionné d’algorithmes de formatage pourrait se manifester, et commencer à travailler sur le problème. Notre travail en tant qu’équipe library est de faire en sorte que cette personne puisse travailler. S’assurer que son projet est en accord avec le reste de la bibliothèque standard, relire son travail et fournir un retour utile et constructif. Si davantage de personnes interviennent pour collaborer sur ce projet, mettre en place un groupe de travail pour aider à tout organiser, etc.

Les entreprises ne font pas travailler le premier venu sur quelque chose. C’est ce qui fait que l’open source est particulier et si génial, si on s’y prend bien.

Objectifs personnels

Idéalement, l’objectif d’un projet open source comme Rust est simplement la combinaison des buts personnels de toutes les personnes travaillant dessus. Et là est la difficulté. Parce que quand une nouvelle personne arrive, on ne lui assigne pas une tâche qui correspond à nos objectifs. Cette personne arrive plutôt avec ses propres objectifs et ses propres idées, les ajoutant à un ensemble déjà assez varié d’objectifs potentiellement conflictuels.

Et c’est pourquoi un projet open source piloté par des bénévoles a besoin d’une structure de management. On ne peut pas juste mettre ensemble une centaine de personnes avec chacune ses propres buts et espérer que tout se passe bien.

Donc ce que fait le management, c’est prendre en considération tous les buts personnels de toutes les personnes travaillant sur un sujet, et essayer de les guider de manière à ce que les choses fonctionnent. Ça peut impliquer le fait de dire non à des idées quand elles seraient incompatibles avec d’autres idées, ou ça peut impliquer beaucoup de discussions pour harmoniser les idées afin qu’elles soient compatibles. C’est exactement l’opposé de la manière dont fonctionne une entreprise typique, où les objectifs viennent d’en haut, et où le management décide de la manière de les répartir et les assigner aux personnes qui effectuent le travail technique.

Alors que beaucoup de projets open source, dont Rust, ont un cap ou un plan d’action, ces derniers doivent reposer sur les objectifs des contributeurs individuels du projet pour que ça fonctionne. Dire « notre objectif principal en 2021 est d’améliorer les mécanismes de formatage dans la bibliothèque standard » devrait faciliter le travail des personnes travaillant déjà dessus, et attirer les personnes qui voulaient déjà travailler sur quelque chose de ce genre. Ça devrait les aider parce que nous priorisons toutes les décisions de management et les révisions de code dont ils ont besoin. Ça devrait permettre aux personnes de se concentrer et d’avancer davantage. Mais sans ces contributeurs, mettre en place de tels objectifs n’a pas de sens. Contrairement à une entreprise, nous n’avons pas à choisir ce sur quoi les personnes passent leur temps, et nous n’employons pas de personnes auxquelles assigner des tâches.

Et c’est une bonne chose.

C’est la raison pour laquelle les gens veulent travailler sur Rust.

Je ne prétends pas qu’un langage de programmation ne pourrait pas être géré « d’en haut » comme une entreprise le ferait. Beaucoup de langages de programmation ont été et sont développés de cette manière avec beaucoup d’efficacité. Ce que je dis, cependant, c’est que personnellement je ne veux pas que le projet Rust fonctionne de cette manière.

Je ne veux pas gérer le département library de l’entreprise Rust. Je veux aider les personnes qui veulent améliorer les bibliothèques du langage Rust.

Un espace pour s’épanouir

Différents contributeurs ont des objectifs très différents, travaillent avec des méthodes très variées, et ont des besoins très différents des structures de management.

Pour certains d’entre eux, nous avons des processus en place destinés à leur rendre le travail plus facile. Une personne qui veut travailler sur une nouvelle fonctionnalité du langage peut soumettre ses idées via une RFC ² et prendre part dans une discussion avec l’équipe library pour des conseils et de l’aide. Quelqu’un qui veut améliorer une grande partie du code du compilateur ³ peut soumettre une proposition de changement majeur (MCP) et en discuter avec l’équipe du compilateur. Et quelqu’un qui veut résoudre un problème dans la bibliothèque standard peut soumettre une proposition de modification et la voir relue et évaluée par des personnes qui connaissent le contexte.

En d’autres termes, nous avons créé un espace pour ces types de contributeurs. De l’espace pour faire leur travail, de l’espace pour obtenir des retours, de l’espace pour obtenir de l’aide, de l’espace pour obtenir une reconnaissance, tout l’espace dont ils ont besoin pour réussir.

Cependant, il existe malheureusement beaucoup de types de contributeurs pour lesquels nous n’avons pas créé un espace, ou pas le bon espace.

Jusqu’à une époque récente, l’équipe library était principalement concentrée sur la conception de l’API. Les problèmes critiques d’implémentation étaient gérés par l’équipe du compilateur par nécessité. Les modifications de code plus modestes étaient relus et évalués par des relecteurs individuels de l’équipe library. Mais il n’y avait pas de gestion prévue pour de plus gros changements de code. Ça signifiait qu’il n’y avait pas d’espace pour une personne qui aurait voulu remettre à neuf le code de std::fmt. Il n’y avait pas d’équipe qu’elle aurait plus rejoindre pour travailler là-dessus, rendant beaucoup plus difficile, voire impossible, d’atteindre son but.

C’est pourquoi j’ai lancé la nouvelle équipe Library.

Faire de la place pour quelque chose peut souvent amener à (accidentellement) retirer de la place pour autre chose. Une personne qui n’est pas très impliquée dans le code mais qui veut appliquer son expérience dans la conception d’API et qui se soucie beaucoup de l’interface de la bibliothèque standard ne s’épanouirait pas dans une équipe qui aime avoir des réunions hebdomadaires à propos des problèmes de correction du code et de la manière avec laquelle résoudre ces problèmes avant la prochaine version publique.

Voilà pourquoi nous avons à présent l’équipe Library API

Nous avons maintenant aussi une équipe de « Contributeurs à Library ». Un endroit pour les personnes qui sont plus impliquées dans le projet que les contributeurs occasionnels, mais qui ne font pas partie des équipes qui prennent les décisions finales. Ça fait de l’espace pour les personnes qui veulent, par exemple, travailler sur seulement un aspect particulier de la bibliothèque, ou aider à relire les modifications proposées. Jusqu’à il y a environ un an, il n’y avait pas d’espace particulier pour qu’une personne relise les changements ou qu’elle s’implique davantage d’autres manières, sans faire directement partie d’une équipe avec beaucoup plus de responsabilités.

J’ai réussi à effectuer ces changements de structure d’équipe avec l’aide des membres des équipes Core et Library, qui m’ont mise en capacité de le faire. En retour, ces changements vont, je l’espère, permettre à des membres de ces nouvelles équipes de s’épanouir, et ainsi permettre à encore plus de personnes de contribuer, pour que finalement cela soit bénéfique pour tous les utilisateurs et utilisatrices du langage.

Continuer à changer

Je n’ai pas l’impression que nous ayons maintenant un espace pour toute personne souhaitant contribuer. Mais une fois que la poussière de la réorganisation se sera dispersée, je pense que le résultat sera une amélioration par rapport à ce que nous avions auparavant, et que ça correspond mieux au projet tel qu’il est aujourd’hui.

« Aujourd’hui » est le mot important ici. Ces équipes sont faites autour des membres actuels et des personnes qui, je pense, pourraient devenir des membres dans un futur proche. Mais ce groupe de personnes et leurs besoins changent, parfois à une vitesse surprenante. Et dans un projet qui est entièrement défini par les personnes qui y contribuent, ça change le projet en lui-même et la structure dont il a besoin, tout aussi rapidement.

En 2018, l’équipe Library était très impliquée dans l’aide aux auteurs des bibliothèques ⁴ populaires de l’écosystème. L’équipe a publié un ensemble de guides, et va réviser les bibliothèques et travailler conjointement avec leurs auteurs pour les implémenter. Tout cela pour améliorer la cohérence et la qualité de l’écosystème de librairies Rust.

Il y a quelques jours encore, c’était toujours techniquement une partie des buts affichés de l’équipe, même si en pratique ça n’était plus vraiment le cas ; particulièrement depuis qu’Ashley Mannix a quitté le projet il y a un moment. Sans les personnes qui ont pour but personnel de faire que des choses se produisent, les choses ne se produisent pas.

Et c’est très bien comme ça.

Tout le monde a une longue liste de vœux pour Rust, de choses qui ne se font pas parce que personne ne travaille dessus. Nous ne sommes pas une entreprise avec des dates limites et des jalons qu’il nous faut absolument atteindre. Nous sommes un groupe, divers et fluctuant, de personnes qui essaient de gérer tout ça avec passion, en s’efforçant de faire en sorte que tous les efforts aboutissent harmonieusement.

Il y a beaucoup de choses pour lesquelles nous devrions avoir de l’espace, mais pour lesquelles nous n’avons encore de place. Mais si nous continuons à essayer, si nous continuons à effectuer de petites améliorations. À nous adapter. À prendre en compte les personnes autour de nous qui veulent contribuer elles aussi ; si nous continuons à réfléchir à la façon dont nous pouvons les aider, eux et tous les autres. Alors chaque pas sera un pas dans la bonne direction, ainsi Rust prospérera et toutes les nombreuses personnes qui travaillent sur Rust et avec Rust s’épanouiront.

Photo « Rusty but pretty »  par Jeanne à vélo, licence CC-BY-SA

Après l’introduction du livre Des routes et des ponts de Nadia Eghbal (si vous avez raté le début…) que le groupe Framalang vous traduit au fil des semaines, voici un aperçu tout simple des composants de base d’un logiciel.

Nos lecteurs les plus au courant n’y trouveront rien qu’ils ne sachent déjà, mais l’intérêt de cette présentation c’est justement qu’elle rend abordables et compréhensibles au grand public des objets techniques qui peuvent s’avérer très complexes à comprendre (…et maîtriser !). On peut dire que la démarche choisie ici, pragmatique et imagée, ne manque pas de pédagogie.
Merci à nos lecteurs soucieux des valeurs du libre de noter que l’auteur n’introduit les notions que progressivement : c’est seulement dans quelques chapitres qu’elle établira clairement une distinction claire qui nous est chère.

Vous souhaitez participer à la traduction hebdomadaire ? Rejoignez Framalang ou rendez-vous sur un pad dont l’adresse sera donnée sur Framasphère chaque mardi à 19h… mais si vous passez après vous êtes les bienvenu.e.s aussi !

De quoi sont faits les logiciels

par Nadia Eghbal

Traduction framalang : Luc, woof, Diane, xi, serici, Lumibd, goofy, alien spoon, flo, salade, AFS, lyn., anthony

Tous les sites web ou les applications mobiles que nous utilisons, même les plus simples, sont constitués de multiples composants plus petits, tout comme un immeuble est fait de briques et de ciment.

Imaginez par exemple que vous désiriez poster une photo sur Facebook. Vous ouvrez votre appli mobile Facebook, ce qui déclenche le logiciel de Facebook pour vous afficher votre fil d’actualités.

Vous téléchargez une photo depuis votre téléphone, ajoutez un commentaire, puis vous cliquez sur « Envoyer ». Une autre partie du logiciel de Facebook, en charge du stockage des données, se souvient de votre identité et poste la photo sur votre profil. Finalement, une troisième partie de ce logiciel prend le message que vous avez saisi sur votre téléphone et le montre à tous vos amis à travers le monde.

Bien que ces opérations aient lieu sur Facebook, en réalité, ce n’est pas Facebook qui a développé toutes les briques nécessaires pour vous permettre de publier sur son application. Ses développeurs ont plutôt utilisé du code libre, public, mis à disposition de tous sur Internet par des bénévoles. Facebook ne publie pas la liste des projets qu’ils utilisent, mais une de ses filiales, Instagram, le fait et remercie certains de ces projets sur sa page d’accueil et dans son application mobile

Utiliser du code public est plus efficace pour des entreprises comme Facebook ou Instagram que de développer à nouveau tous les composants par elles-mêmes. Développer un logiciel est comparable à la construction d’un immeuble. Une entreprise du bâtiment ne produit pas ses marteaux et ses perceuses, et n’ira pas non plus chercher du bois pour découper les troncs en planches.

Elle préférera les acheter à un fournisseur et se fournir en bois auprès d’une scierie pour finir le travail plus rapidement.

Grâce aux licences permissives, les sociétés telles que Facebook ou Instagram ne sont pas obligées de payer pour ce code, mais sont libres d’en profiter grassement. Ce n’est pas différent d’une entreprise de transport (Instagram) qui utilise les infrastructures routières publiques (code public) pour acheminer ses produits à des fins commerciales (application Instagram).

Mike Krieger, un des co-fondateurs d’Instagram, a insisté sur ce point en 2013 et encouragé d’autres entrepreneurs à :

emprunter plutôt que construire à chaque fois que c’est possible. Il existe des centaines d’excellents outils qui peuvent vous faire gagner du temps et vous permettre de véritablement vous concentrer sur le développement de votre produit. (source)

Voici quelques-uns des outils utilisés par une entreprise de logiciels :

Frameworks (environnements de développement)

Les framewoks offrent une base, une sorte d’échafaudage, une structure. Imaginez cela comme un schéma pour toute une application. Comme un plan, un framework définit la manière dont l’application se comportera sur mobile, ou comment ses données seront sauvegardées dans une base de données. Par exemple Rails et Django sont des frameworks.

Langages

Les langages de programmation constituent l’épine dorsale de la communication des logiciels, comme la langue anglaise (NdT : aux USA bien sûr) qu’emploient les ouvriers du bâtiment sur un chantier pour se comprendre. Les langages de programmation permettent aux divers composants du logiciel d’agir et de communiquer entre eux. Si par exemple vous créez un compte sur un site internet et que vous cliquez sur « S’enregistrer », cette application peut utiliser des langages comme le JavaScript ou le Ruby pour sauvegarder vos informations dans une base de données.

Parmi les langages de programmation les plus populaires on peut mentionner le Python, le JavaScript et le C.

Bibliothèques

Les bibliothèques sont des fonctions pré-fabriqués qui accélèrent l’écriture du code d’un logiciel, tout comme une entreprise du bâtiment achète des fenêtres préfabriquées au lieu de les assembler à partir des composants de base. Par exemple, au lieu de développer leur propre système d’identification pour les utilisateurs de leur application, les développeurs et développeuses peuvent utiliser une bibliothèque appelée OAuth. Au lieu d’écrire leur propre code pour visualiser des données sur une page web, ils ou elles peuvent utiliser une bibliothèque appelée d3.

Bases de données

Les bases de données stockent des informations (profils d’utilisateurs, adresses électroniques ou codes de cartes bancaires par exemple) qui peuvent être utilisées par l’application. À chaque fois qu’une application a besoin de se souvenir d’une information qui vous concerne, l’application la stocke dans la base de données. Parmi les systèmes de gestion de bases de données (SGBD) les plus populaires on trouve notamment MySQL et PostgreSQL.

Serveurs web et d’applications

Ces serveurs gèrent certaines requêtes envoyées par les utilisateurs sur Internet : on peut les voir comme des centrales téléphoniques qui répartissent les appels. Par exemple, si vous saisissez une URL dans la barre d’adresse de votre navigateur, un serveur web vous répondra en vous envoyant la page concernée. Si vous envoyez un message à un ami sur Facebook, le message sera d’abord envoyé à un serveur d’applications qui déterminera qui vous essayez de contacter puis transmettra votre message au compte de votre ami.

Parmi les serveurs web très répandus, citons Apache et Nginx.

Certains de ces outils, comme les serveurs et les bases de données, sont coûteux, surtout à l’échelle d’une entreprise, ce qui les rend plus faciles à monétiser. Par exemple, Heroku, une plate-forme sur le cloud (sur un serveur distant) qui fournit des solutions d’hébergement et de bases de données, propose une offre de base gratuite, mais il faut payer pour avoir accès à plus de données ou de bande passante. De grands sites reposent sur Heroku comme ceux de Toyota ou de Macy, et l’entreprise a été rachetée en 2010 par Salesforce.com pour 212 millions de dollars.

Il est plus difficile de faire payer d’autres types d’outils de développement, tel que les frameworks, de nombreuses bibliothèques et langages de programmation, qui sont souvent créés et maintenus par des bénévoles.

Ce type d’outils ressemble plus à des ressources qu’à des services qui peuvent être activés ou désactivés : les rendre payants limiterait fortement leur adoption. C’est pourquoi n’importe qui, que ce soit une entreprise milliardaire ou un adolescent apprenti développeur, peut utiliser gratuitement ces composants pour créer ses propres logiciels.

Par exemple, selon la page d’accueil d’Instagram, l’une des bibliothèques utilisées par l’entreprise est Appirater. Il s’agit d’une bibliothèque qui facilite les fonctions de rappels automatiques pour l’évaluation d’une application, à destination des utilisateurs d’iPhone. Elle a été créée en 2009 par Arash Payan, un développeur indépendant basé à Los Angeles. Le projet n’apporte aucun revenu à Payan.

C’est comme si des scieries, des centrales à béton et des magasins de matériel donnaient leurs matériaux de base à une entreprise du bâtiment, puis continuaient à approvisionner cette entreprise.

À l’occasion de la journée Ada Lovelace, Véronique Bonnet, professeur de philosophie et administratrice de l’April, s’adresse à cette femme illustre et la replace dans une perspective libriste, sans la réduire à la caution féministe d’une journée singulière…

Ada,

honorable Lady Augusta Ada King, comtesse de Lovelace, ta journée est un peu ambigüe, mais sans doute nécessaire.

L’idée d’un Ada Lovelace Day n’est pas des plus subtiles. Marquer d’une pierre blanche un jour de notre année pour y honorer une programmeuse non pas parce qu’elle est programmeuse mais parce qu’elle est femme, et qu’il est inouï qu’une femme le soit, et qu’en plus on dise qu’elle ait été la première à l’être, la première des programmeuses et des programmeurs, c’est comme poser l’exception qui confirme la règle. C’est faire d’une fête une défaite, un peu. Sûrement pas la défaite des femmes, mais plutôt la défaite de l’autonomie, celle qui amène les êtres parlants à se moquer pas mal d’avoir eu de petits chaussons roses ou de petits chaussons bleus, dans l’invention d’eux-mêmes qu’est l’existence.

Nous le savons bien, dans la communauté, à l’April, à Framasoft : rien de tel que le librisme pour conjuguer le « fais ton informatique comme tu veux », adage stallmanien, sur le mode « fais ta vie comme tu veux ». Libriste s’écrit de la même façon au féminin et au masculin. L’archétype du programmeur mâle, blanc, trentenaire, par la grâce d’une éthique du libre, finira bien par partir en quenouille.

Mais ce serait oublier, Ada, qu’il y a encore aujourd’hui des pays où les filles ne vont même pas à l’école. Et où de tristes alibis, comme la religion ou parfois la culture, finissent par les persuader elles-mêmes, faute de recul, que tout est bien ainsi.

Chez Platon, lui-même, dans le Banquet, il est vulgaire de s’éprendre d’un corps féminin, qui ne pense pas, et qui est tout juste bon à fournir la part de matière requise pour qu’il y ait procréation, expression naïve du désir d’immortalité. L’être masculin, lui, a un corps qui pense. Lorsqu’il se reproduit, il est pourvoyeur non pas de matière mais de forme. De manière imagée, à la fin du Timée, le même Platon précise : quand un être masculin, qui donc peut penser, néglige de le faire, il devient femme. S’il persiste dans son absence de fréquentation de l’intelligible, il devient oiseau, tête de linotte, puis mammifère terrestre, puis reptile, poisson, mollusque. S’il se remet à penser, le mollusque devient poisson, puis reptile, puis mammifère, puis femme, puis homme…

Il faut attendre l’humanisme de la Renaissance pour que soit posée la tâche, pour chaque humain, qu’il soit masculin ou féminin, de s’inventer lui-même, d’inventer son rapport au sensible et à l’intelligible. Non plus être un corps, mais avoir un corps, non plus s’inscrire seulement dans des sens, mais dans du sens. C’est aussi à la Renaissance (comme je l’avais évoqué dans un article précédent du Framablog : Sensibilité, fraternité, logiciel libre) que les alchimistes, dont Paracelse, rêvent de générer un être qui pense, sans l’entremise du féminin. Ce à quoi feraient écho, selon Philippe Breton, les projets des cybernéticiens et des informaticiens : faire advenir, par le potentiel de l’abstraction mathématique, une intelligence artificielle. Persistance, aujourd’hui, de ces représentations, dans la question du rapport des femmes à la science ?

Portrait d’Ada Lovelace par Alfred Chalon (Domaine public, via Wikimedia Commons) 

Tu es née, Ada, en 1815, en un temps où une enfant de lord, Byron en l’occurrence, n’aurait jamais dû être initiée à la mathématique. Un contexte très particulier : ta mère mathématicienne, ton père parti, après ta naissance, épouser une autre femme, sans jamais te revoir. Ce qui a ouvert pour toi ce qui était fermé pour toutes les autres. Wikipédia se fait l’écho, à ton sujet, de commentaires contradictoires concernant la part de Charles Babbage dans les initiatives théoriques qui te sont attribuées, concernant la programmation de la machine ainsi que l’intuition d’implémentation de symboles. Première à avoir programmé ou non, tu fus, en tous cas, pionnière émérite et virtuose arithméticienne à un moment qui en comptait peu d’autres.

Émilie, Gabrielle Émilie Le Tonnelier de Breteuil, marquise du Châtelet, un siècle avant toi, mathématicienne, et physicienne aussi,  avait traduit Newton, aimé Voltaire, et prêté le flanc aux commentaires acerbes des chipies jalouses d’alors. Une certaine Madame du Deffand, réputée pourtant pour son esprit et son salon fréquenté par les Lumières, avait écrit d’Émilie du Châtelet : « sans talents, sans mémoire, sans goût, sans imagination, elle s’est faite géomètre pour paraître au-dessus des autres femmes, ne doutant pas que la singularité ne donnât la supériorité. »

Émilie est morte en couches. Toi-même, Ada, d’un cancer de l’utérus. Comme si, par là, marâtre, la nature s’était ingéniée à souligner ce à quoi les femmes devraient s’en tenir lorsqu’elles « conçoivent ». Conception, et non pas concept. Filles d’Eve, comme chacun sait, et non d’Adam. Du côté du sensible, non de l’intelligible. Comme si ce clivage avait un sens à lui tout seul. Heureusement, il est très beau, Ada, que ton nom ait été donné à un langage.

C’est pourquoi, Ada, pour te rendre« hommage », terme piégé, encore, et c’est bien dommage, je m’en tiendrai à ceci :

En cet Ada Lovelace Day, à l’encontre des idéologies privatrices, tu opères comme figure tutélaire, et avant tout humaine, de l’ingéniosité. Aussi bien Ada que Charles. Aussi bien Ian que Deb. Aussi bien Ulysse aux mille ruses que Pénélope et son hack de la toile, filée le jour et détricotée la nuit. Après tout, Pénélope est devenue reine d’Ithaque sur la requête de son navigateur.

Ces dernières années, il n’y a pas de formation pour enseignants, de lettre ministérielle, d’exposition à destination des enfants qui ne parle pas de « parcours pédagogique ». Derrière ce grand terme fourre-tout on trouve globalement l’idée de faire passer l’apprenant par différentes étapes afin de lui permettre d’acquérir une notion, une compétence… Si on veut que ce parcours soit réellement pertinent et utile, il doit pouvoir s’adapter aux différents utilisateurs. C’est là que l’utilisation d’outils numériques peut prendre tout son sens.

Quelques outils existent dans l’univers du libre. L’association Sésamath développe par exemple le superbe projet J3P, très orienté pédagogie, qui permet à l’élève de créer son parcours parmi les différents exercices planifiés par l’enseignant en fonction de ses réponses.
Sur Framagora, nous avons eu la chance de voir l’évolution d’un projet plus ludique : JLoDB. Son auteur, Johann, nous présente sa réalisation.

Bonjour Johann, peux-tu nous présenter jLoDB ?

Bonjour. jLoDB est l’acronyme de « Javascript Learning Object Database ». C’est une base de données d’activités éducatives ; « éducatives » au sens large car il existe en son sein de nombreuses activités plus ludiques qu’éducatives : le Sudoku, Picross, Sokoban et d’autres encore. Ce projet se présente comme un site web tout ce qu’il y a de plus classique que chacun est libre d’utiliser, d’installer et de modifier comme le permet sa licence GPL-3.

L’architecture de jLoDB est modulaire. Il existe un noyau principal qui est la base de données où sont référencés tous les exercices en fonction de leur difficulté, de leur durée moyenne, de leur champ d’application et d’autres choses encore. Chaque exercice réalisé par l’utilisateur est évalué automatiquement par le programme qui lui donne une note de A à F.

Là-dessus, il est possible de développer des modules qui vont faire usage de cette base et de ces exercices. Parmi les modules actuellement disponibles on peut citer « Dä » qui est une sorte de trivial pursuit où chaque case donne lieu à un exercice issu de la base, « TiBibi » qui permet à un utilisateur de préparer et de stocker ses propres séries d’exercices et finalement « Genius socialis » qui organise les exercices suivant un parcours pédagogique.

Quelle est son originalité ?

D’un point de vue technique, jLoDB se veut le plus accessible possible. Le logiciel est très peu gourmand en ressources et doit pouvoir fonctionner sur tout type de matériel, même ancien. Ensuite, il repose sur des technologies libres et largement répandues (html et javascript côté client, apache, php et mysql côté serveur). En outre, l’utilisation du clavier est facultative rendant le projet compatible avec une utilisation sur tablette. Enfin, l’usage exclusif d’un format graphique vectoriel rend les activités indépendantes de la résolution de l’écran. Le petit bémol vient de la compatibilités des navigateurs puisque seul Firefox est totalement compatible. Safari, s’en sort très bien aussi, mais il souffre d’un bug d’affichage parfois pénalisant tout comme Chrome qui, en plus, ne supporte pas MathML, un format d’affichage de formules mathématiques. Internet Explorer n’est pas supporté.

Au niveau interface et jouabilité, je me suis énormément inspiré de ce qui se faisait dans le domaine du jeu vidéo. Même la représentation du parcours pédagogique est très inspiré par le sphérier de « Final Fantasy XII » ou l’arbre de compétences de « Path of exile ». Également, je suis un grand fan de logiciels comme « Docteur Kawashima » ou « Professeur Layton » qui, avec un game design astucieux, parviennent à rendre passionnant des problèmes parfois complexes. J’ai donc essayé d’appliquer le plus possible ces principes de gamification et j’espère que pour un projet éducatif, jLoDb arrive à proposer des choses ludiques et amusantes dans l’ensemble.

Enfin, du point de vue du contenu lui-même, certaines activités référencées dans la base me semblent assez peu communes.

• 4 activités de programmation (Robot, LOGO, programmation impérative et Assembleur 6502) permettent à l’utilisateur d’apprendre l’informatique et la programmation de façon totalement autonome. C’est probablement la partie la plus développée actuellement. À l’heure où il est question de l’apprentissage de l’informatique à l’école, je crois sincèrement que jLoDb apporte une réponse tout à fait crédible.
• L’activité « Équation » (inspiré par l’excellent « Dragon Box Algébra ») permet de résoudre des systèmes d’équations à plusieurs inconnus par simple manipulation d’éléments graphiques.
• L’activité « MathCraft » (j’adore ce nom) propose des exercices de preuves mathématiques où l’utilisateur doit prouver une hypothèse à partir d’éléments fournis par

  

  l’énoncé. C’est encore assez expérimental et le formalisme de l’activité est un peu complexe, mais je trouve que cela donne des résultats plutôt prometteurs.

Maintenant qu’on connait un peu mieux ton projet, peux-tu te présenter un peu ? Quel est ton « parcours » ?

Je suis ingénieur en développement informatique. Dans la vraie vie, je bosse sur des programmes de gestion de flux de données. C’est un boulot intéressant car technique et exigeant mais, en même temps, il est assez frustrant parce qu’au final, il n’y a rien à montrer. Il n’y a aucun résultat visible : pas de jolies interfaces, aucune image, juste des flux de données et quelques logs. C’est, je crois, pour cette raison que j’ai commencé à programmer à la maison, pour moi, pour me faire plaisir. J’ai commencé par un logiciel de dessin sur Android en version 1.6 (« Plouik ») puis quelques jeux en SDL sous Linux avec un framework développé pour l’occasion (« Splashouille »).

Je suis honnêtement admiratif du boulot que tu as abattu seul. Depuis combien de temps travailles-tu sur ce projet ? Cela représente combien d’heures ?

Merci. Je ne saurais dire exactement. Si j’en crois mon compte GitHub, le dernier submit de « GNU versus zombie rotten tomatoes » (mon dernier développement hors jLoDb) remonte au 25 Juillet 2012. Je pense que cela doit correspondre au début du développement du projet. J’ai commencé par le jeu de l’alchimiste (Note De Moi : Je vous conseille de tester, c’est assez addictif comme jeu) et je me souviens l’avoir ré-écrit au moins 2 fois avant de trouver une structure satisfaisante, assez proche de ce qu’elle est encore aujourd’hui. Au niveau du temps passé, je ne saurais non plus dire. Tout cela est fait sur mon temps libre. J’essaie de développer un peu tous les jours mais cela est très fluctuant.

Je crois savoir que ton idée initiale était un seul et unique parcours dans lequel l’utilisateur pourrait progresser à n’importe quel moment de sa vie ? Cela ne te semble pas un peu audacieux comme projet ?

Tout provient d’un constat assez simple. En tant que joueur occasionnel, j’ai passé un temps incroyable sur de jeux comme « angry birds », « candy crush » ou « puzzle and dragons » à enchaîner des actions parfois très répétitives, à faire et refaire les mêmes niveaux, à me lever plus tôt le matin pour finir une quête quelconque. Les principes de gamification ont aujourd’hui une telle efficacité qu’il est souvent difficile de décrocher. L’idée sous-jacente du projet jLoDb est donc d’utiliser ces techniques de gamification sur des domaines plus académiques afin de créer une addiction à l’apprentissage.

Donc oui, pour répondre à la question, c’est extrêmement ambitieux (et pas mal prétentieux, aussi).

Ça l’est d’autant plus que je suis convaincu désormais qu’il est tout à fait possible d’intégrer la quasi-totalité des matières universitaires, de l’apprentissage de la lecture aux domaines post-bac (comme la thermodynamique ou la médecine). Le travail à accomplir est colossale mais au combien passionnant.

Tes graphismes sont très soignés. C’est toi qui fait tout cela également ? Avec quels logiciels ?

C’est gentil. Pour l’heure, j’ai réalisé l’ensemble des graphismes. J’ai cherché un peu à côté, mais j’avoue ne pas avoir trouvé grand chose. J’ai toujours aimé dessiner et mon petit niveau me permet de faire parfois illusion.Tous les graphismes sont vectoriels, du coup, j’utilise essentiellement Inkscape. Parfois, lorsque l’illustration à réaliser est très géométrique, il m’arrive de « dessiner » directement à l’aide d’un simple éditeur texte profitant du fait que le format vectoriel SVG est un format descriptif parfaitement lisible.

Par contre, pour le moment, les consignes des activités ne me semble pas forcément toutes toujours très claires. Besoin d’un coup de main ?

C’est un problème très récurrent avec mes développements. J’ai eu le même souci sur mon logiciel de dessin que je trouvais personnellement très intuitif mais qui, compte tenu des retours utilisateurs, ne l’était pas tant que cela.

Cela dit, je ne trouve pas que cela soit un problème en soit. Selon moi, le vrai souci est que le contenu du projet (les exercices mais aussi le parcours pédagogique) ne doit pas être rédigé par une seule personne. C’est un non-sens absolu. Surtout pour un projet libre (et surtout quand la dite personne n’a aucune compétence pédagogique). Si je le fais actuellement c’est faute de mieux car il faut bien pouvoir présenter quelque chose, mais il est clair que ce n’est pas une bonne chose. Donc oui, j’ai clairement besoin d’aide.

De manière générale, comment fait-on si on a envie de t’aider ?

Il y a plusieurs façons d’aider le projet. J’ai rédigé une notice dans un forum de discussion créé pour l’occasion (et encore un peu vide). Y sont détaillées les différentes façons de participer au projet.

Actuellement mon plus gros problème est la scénarisation et la validation du parcours pédagogique. Je n’ai aucune compétence pédagogique, aussi « Genius Socialis » ne doit pas être utilisé par des élèves. Pas encore. Pour qu’il soit exploitable, il faut, au préalable, qu’un groupe de personnes motivées organise et valide ces différentes séries d’exercices. Je pense que cela peut se faire via le forum car tous les outils nécessaires sont déjà disponibles. Donc, si cela vous intéresse n’hésitez pas à me contacter.

Et si je veux moi aussi installer jLoDB sur le serveur de mon école, c’est facile ? Tu as eu le temps de documenter cela quelque part ?

C’est facile au sens où c’est une installation relativement commune. Il faut disposer d’un serveur web. Le trio Apache, mySQL et PHP est largement suffisant. Il n’y a alors plus qu’à copier le projet dans l’arborescence web, modifier le fichier de configuration conf/jlodb.ini et lancer l’installation depuis la page principale du site. Rien de bien compliqué au final. J’ai mis un peu de documentation au niveau du forum de discussion.

Pourquoi le choix d’une licence libre (GPL 3) ? Tu aurais pu faire le choix du propriétaire, vendre cette solution à un éditeur scolaire et prévoir ainsi le remplacement de tes usines à spermatozoïdes par du métal précieux.

Pourquoi une licence libre ? À vrai dire, la question ne s’est pas vraiment posée : c’était une évidence dès le départ. Tout autre type de licence n’aurait fait que brider la diffusion du projet. Ce n’est pas ce dont j’avais envie.

Tu vas me trouver curieux (et cette question n’intéressera surement pas vraiment nos lecteurs), mais pourquoi as-tu choisi « Pouf-Pouf Production » comme nom de domaine ? Envie de concurrencer notre framaslave du domaine public dans les noms incongrus ?

Je pense que le choix de noms incongrus devrait être une obligation pour tous les développements non professionnels. C’est en tous cas le choix que j’ai fait en utilisant des noms parfaitement ridicules ou sans réelle signification sur l’ensemble de mes projets.

Initialement, « Plouik », mon logiciel de dessin sous Android et publié sous GooglePlay s’appelait « Sketchbook ». J’avais vérifié que ce nom n’était pas utilisé sur le market de Google mais je n’étais pas allé plus loin à l’époque. Si bien que quelque temps plus tard, j’ai reçu une lettre des avocats d’Autocad me demandant de dépublier expressément le logiciel sous peine de poursuites. Il est vrai qu’un « Autocad Sketchbook » existait déjà sur d’autres supports et, il a même été porté sous Android depuis.

J’ai donc changé le nom du logiciel. Mais, au final, le problème ne s’arrête pas là. Car même si le nom n’existe pas encore, il peut être déposé par une entreprise plus tard. Et le problème se reposera. Donc, pour éviter tout souci, le plus simple est, selon moi, de choisir, dès le départ, des noms dont personne ne veut, ni ne voudra jamais. Noms ridicules, imprononçables ou totalement incongrus : le choix reste très vaste.

Merci Johann pour cet entretien.

Le travail intellectuel des programmeurs souffrirait-il d’un manque de visibilité et de reconnaissance aux yeux d’une logique managériale qui cherche à mesurer le travail effectif avec des critères dépassés ? C’est ce que laisse entendre ce témoignage qui au détour d’une plaisante anecdote met l’accent sur un relatif malaise d’une profession qu’il est difficile de cerner de l’extérieur, et même de l’intérieur d’une entreprise.

Are Your Programmers Working Hard, Or Are They Lazy? article paru sur le blog de l’auteur

Traduction Framalang : sinma, goofy, KoS

Vos programmeurs travaillent-ils dur, ou sont-ils fainéants ?

par Mike Hadlow

Quand quelqu’un effectue une tâche physique, il est facile d’évaluer à quel point il travaille dur. Vous pouvez le voir physiquement en mouvement et en transpiration. Vous pouvez aussi voir le résultat de son travail : le mur de briques s’élève, le trou dans le sol devient plus profond. Reconnaître et récompenser un dur labeur est un instinct assez fondamental chez l’être humain, c’est l’une des raisons pour lesquelles nous trouvons les sports d’endurance si fascinants. Cette reconnaissance d’un dur travail physique devient un problème quand on l’applique à la gestion de personnes qui travaillent à des activités techniques ou créatives. Souvent, les travailleurs intellectuels efficaces n’ont pas l’air de travailler très dur.

En 2004, j’étais développeur junior dans une grande équipe qui s’occupait du système de fourniture et de facturation d’une entreprise de télévision par câble. Comme tous les grands systèmes, il était constitué de plusieurs unités relativement indépendantes dont s’occupaient des personnes ou des équipes différentes. Les départements de TV analogiques et numériques étaient presque entièrement séparés, pris en charge par des équipes différentes.

L’équipe de la TV analogique avait décidé de fonder son système autour d’une pré-version de Microsoft Biztalk. Quatre gars de chez nous et une équipe de Microsoft le développaient et le faisaient tourner en production. Ils avaient tous l’air de travailler très dur. On les voyait souvent travailler tard dans la nuit et pendant le weekend.

Chacun laissait tomber ce qu’il était en train de faire si un problème survenait en production, ils se réunissaient souvent autour du bureau d’un type, faisaient des suggestions pour régler ce qui n’allait pas, ou pour réparer quelque chose. L’activité était permanente, et tout le monde pouvait voir non seulement qu’il y avait un véritable esprit d’équipe, mais que tout le monde travaillait très très dur.

L’équipe chargée de la TV numérique était tout à fait différente. Le code avait été, en majorité, écrit par une seule personne que l’on appellera Dave. Il était développeur de maintenance junior dans l’équipe. Au départ, j’ai eu beaucoup de difficultés à comprendre le code. Au lieu d’une seule longue procédure dans un endroit précis où tout le travail se serait effectué, il y avait des tas de petites classes et méthodes avec seulement quelques lignes de code. Plusieurs collègues se plaignirent que Dave rendait les choses extrêmement compliquées. Mais Dave me prit sous son aile et me conseilla de lire quelques livres sur la programmation orientée objet. Il m’apprit les patrons de conception, les principes SOLID, et les tests unitaires. Le code commença alors à avoir du sens, et plus je travaillais dessus plus j’appréciais l’élégance de sa conception. Il ne posait pas de problème en phase de production, il ronronnait dans son coin et faisait le boulot. Il était assez facile d’opérer des modifications dans le code, du coup l’implémentation de nouvelles fonctionnalités se faisait souvent sans aucun problème. Les tests unitaires permettaient de trouver la plupart des bugs avant la mise en production.

Le résultat de tout cela est que nous n’avions pas l’air de travailler très dur du tout. Je rentrais chez moi à 18h30, je ne travaillais jamais pendant les weekends, nous ne passions pas des heures attroupés autour du bureau de quelqu’un d’autre pour deviner le problème avec un quelconque système planté en production. De l’extérieur, notre tâche devait sembler beaucoup plus facile que celle des gens de la TV analogique. En vérité, les exigences étaient très similaires, mais nous avions un logiciel mieux conçu et implémenté, et une meilleure infrastructure de développement, notamment les tests unitaires.

La direction fit savoir que des augmentations seraient accordées sur la base de nos performances. Quand ce fut mon tour de parler au directeur, il expliqua qu’il était normal que les augmentations soient accordées à ceux qui travaillaient vraiment dur, et que l’entreprise ne semblait pas importer beaucoup à notre équipe, au contraire de ces héros qui lui consacraient leurs soirées et leurs weekends.

photo par nic’s events – CC BY-SA 2.0

Cette entreprise était l’un des rares laboratoires où l’on pouvait comparer directement les effets d’une bonne ou d’une mauvaise conception logicielle et le comportement d’une équipe. La plupart des organisations ne permettent pas une telle comparaison. Il est très difficile de dire si ce type, transpirant sang et eau, travaillant tard les soirs et weekends, constamment sur la brèche, fait preuve d’une grande volonté pour faire fonctionner un système vraiment très complexe, ou s’il est simplement nul. Sauf si vous pouvez vous permettre d’avoir deux ou plusieurs équipes concurrentes travaillant à résoudre le même problème, mais bon, personne ne fait ça, on ne saura donc jamais. Et au contraire, le type assis dans son coin, travaillant de 9 heures à 17 heures et qui semble passer beaucoup de temps à lire sur internet ? Est-il très compétent pour écrire un code stable et fiable, ou son boulot est-il plus facile que celui des autres ? Pour l’observateur moyen, le premier travaille vraiment dur, pas le second. Travailler dur c’est bien, la paresse c’est mal, n’est-ce pas ?

Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec. Le développement logiciel est souvent mal fait dans un environnement sous pression et dans lequel on est souvent interrompu. Ce n’est généralement pas une bonne idée de travailler de longues heures. Quelquefois, la meilleure façon de résoudre un problème est d’arrêter d’y penser, d’aller prendre l’air, ou encore mieux, de prendre une bonne nuit de sommeil et de laisser faire notre subconscient. Un de mes livres favoris est « A Mathematician’s Apology » (traduit sous le titre L’apologie d’un mathématicien) par G. H. Hardy, un des mathématiciens anglais les plus importants du XX^e siècle. Il y décrit sa routine : quelques heures de travail le matin suivies par un après-midi à regarder le cricket. Il dit qu’il est inutile et contre-productif d’effectuer un travail mental intensif plus de quatre heures par jour.

photo par sfllaw – CC BY-SA 2.0

J’aimerais dire aux manageurs de juger les gens en regardant leurs résultats, leurs logiciels qui tournent bien, et non en regardant si les programmeurs ont l’air de travailler dur. C’est contre-intuitif, mais il est sans doute préférable de ne pas vous assoir tout près de vos développeurs, vous pourrez ainsi avoir une meilleure idée de ce qu’ils ont produit, sans être affecté par des indicateurs conventionnels ou intuitifs. Le travail à distance est particulièrement bénéfique ; vous devez apprécier vos employés pour leur travail, plutôt que par la solution de facilité qui consiste à les regarder assis à leur bureau 8 heures par jour, martelant de façon lancinante sur leur IDE, ou se pressant autour du bureau des autres pour offrir des suggestions « utiles ».

Coup sur coup cet été à La Réunion et à Strasbourg, j’ai utilisé le logiciel Scratch pour illustrer mes conférences.

Je racontais alors l’expérience de mon élève Lucas, étiquetté « en difficulté scolaire » et qui s’était tout d’un coup totalement réveillé lorsque j’avais présenté le logiciel à la classe (jusqu’à m’envoyer le soir même dans ma boîte mail une première version d’un jeu original créé en quelques heures dans la foulée du retour chez lui)^[1].

Un jour, peut-être, je trouverai le temps de relater plus en détails cette belle histoire dans un billet dédié à cet extraordinaire logiciel qu’est Scratch. Mais en attendant d’autres le font tout aussi bien que moi, en apportant en prime une réflexion globale sur les atouts et les avantages de ce type de logiciel dans le processus d’apprentissage et de sociabilisation.

Ici non seulement les enfants sont créatifs, mais créatifs à coté des autres et souvent même créatifs ensemble. Et c’est alors bien moins le fait d’utiliser des logiciels libres qui est important ici que celui d’adopter son modèle et son état d’esprit dans le processus de création,

Un cas d’école tout au long de la vie

A Case for Lifelong Kindergarten

Tina Barseghian – 26 septembre 2011 – MindShift
(Traduction Framalang : Goofy, Poupoul2, Mammig, Duthils, Sysy, Julien)

Est-ce que le meilleur environnement d’apprentissage ne serait pas le jardin d’enfants ?

Voilà une proposition surprenante qui fait partie de celles qu’envisagent des gens comme Mitch Resnick au MIT. Il s’agit du créateur de Scratch, un logiciel bien connu d’initiation à l’informatique pour débutants.

Resnick a exprimé cette idée la semaine dernière au sommet l’École de Demain soutenu par le New York Times, et y a proclamé que « les écoles devraient ressembler au chaos », un commentaire qui a enflammé la Twittosphère.

Resnick est l’un des trois lauréats du Prix McGraw de l’éducation, avec le professeur de physique Robert Beichner et Julie Young, présidente de l’École Virtuelle de Floride. Ils ont tous les trois co-écrit un article qui illustre pourquoi et comment la technologie devrait s’intégrer harmonieusement dans le processus d’apprentissage tout au long de la vie.

Voici la partie de l’article écrite par Resnick, qui cite lui-même plusieurs extraits de A New Culture of Learning: Cultivating the Imagination for a World of Constant Change de Doug Thomas et Johne Selly Brown.

Mitch Resnick

Notre objectif, au Media Lab du Massachussets Institute of Technology, est de créer des technologies qui donnent la possibilité à tout un chacun d’explorer, d’expérimenter et de s’exprimer différemment. Le groupe La Maternelle tout au long de la vie (NdT : Lifelong Kindergarten group), dont je fais partie, développe des outils pour faire vivre des expériences d’apprentissage créatif, tout en mettant l’accent sur des activités collaboratives et motivantes telles que traditionnellement utilisées dans les écoles maternelles.

Nous nous inspirons de la façon dont les élèves du jardin d’enfants apprennent en spirale : ils imaginent ce qu’ils veulent réaliser, créent un projet basé sur leurs idées, jouent individuellement avec leur création, puis partagent leurs idées et conceptions les uns avec les autres et réfléchissent alors à leur retour d’expérience. Tout ceci les conduit à concevoir de nouvelles idées et de nouveaux projets. Ce processus récursif d’apprentissage est une préparation idéale à la société très évolutive d’aujourd’hui, dans laquelle les gens doivent constamment élaborer de nouvelles solutions face aux situations inattendues qu’ils ne manqueront pas de rencontrer dans leur vie.

Nous travaillons à développer de nouvelles technologies qui, comme les cubes et la peinture au doigt de la maternelle, élargissent l’étendue de ce que les gens peuvent concevoir, créer et apprendre — et ainsi semer les graines d’une société de demain plus créative. Notre but est d’apprendre aux enfants à penser créativement, à travailler collaborativement, et à apprendre constamment — des compétences essentielles pour réussir au XXIe siècle. Nous développons une nouvelle génération de technologies qui non seulement permettent aux enfant de s’accrocher à de nouveaux concepts et à de nouvelles idées mais aussi de communiquer avec d’autres personnes, en offrant de nouvelles voies au partage, à la collaboration et à l’empathie envers tout un chacun.

Voici deux exemples, parmi mes projets, qui illustrent ce point : Scratch et le Club informatique.

Scratch est un environnement graphique de programmation destiné aux enfants de huit ans et plus. Il leur facilite la création de leurs propres histoires interactives, jeux, dessins animés et simulations — ils peuvent ensuite partager en ligne leurs créations. Environ 1 000 000 d’enfants ont rejoint la communauté en ligne de Scratch et ils y partagent plus de 2 000 projets Scratch tous les jours.

L’entrain avec lequel les enfants utilisent cette communauté en ligne démontre à quel point les relations sociales peuvent être encouragées par de nouveaux outils numériques. Les membres de la communauté Scratch sont alternativement élèves et enseignants, résolvent des problèmes et perfectionnent les programmes tous ensemble. L’extrait suivant de A New Culture of Learning: Cultivating the Imagination for a World of Constant Change, un livre récemment publié par Doug Thoas et John Seely Brown, décrit l’aventure d’un enfant de neuf ans, Sam, qui utilise Scratch pour créer ses propres jeux animations.

Scratch a quelque chose en plus qui conduit l’expérience à un niveau différent : la collectivité, une communauté d’individus avec des idées semblables qui aide Sam à apprendre et répond vraiment à ses besoins. Quand Sam publie son jeu en ligne dans cet environnement, il devient accessible à des centaines d’autres enfants qui travaillent également avec Scratch, et c’est de cette façon que les choses intéressantes commencent. Les autres joueurs ne font pas que jouer avec le jeu de Sam, car d’un simple clic sur un bouton, ils peuvent le charger dans leur propre interface de Scratch, voir le code source, et le modifier s’ils le souhaitent.

L’une des fonctions les plus importantes du site réside dans le fait que les utilisateurs ont la possibilité de commenter un projet qu’ils aiment en cliquant sur un bouton « Tu aimes ça ? » (NdT : Love it?). Ce dont Sam s’est aperçu en rejoignant les autres en ligne c’est qu’il ne créait pas uniquement des animations ou des jeux ; il faisait partie d’une communauté.

Il a bien évidemment été très enthousiaste de recevoir son premier commentaire. Mais quand nous avons demandé à Sam ce que signifiait pour lui faire partie de la communauté de Scratch, nous avons été surpris de sa réponse qui n’avait rien à voir avec la conception de jeux ou la diffusion d’animations. Sam nous a simplement dit que la chose la plus importante est de ne pas être méchant dans ses propos et de laisser des commentaires positifs quand on croise quelque chose de bien. Le jeu ne sert pas uniquement à apprendre à programmer ; il cultive aussi la citoyenneté.

Sam nous a peut-être fait le commentaire le plus révélateur de cette nouvelle culture de l’apprentissage. Quand nous lui avons demandé ce qu’il recherchait dans les programmes des autres. Il nous a dit : « quelque chose de très cool que je n’aurais jamais pu faire et connaître seul. » En jouant avec Scratch, Sam a appris beaucoup sur la programmation et sur la participation aux communautés en ligne. Mais ce qu’il a avant tout retenu c’est comment apprendre des autres.

L’exemple suivant illustre comment une fille agée de 13 ans, identifiée par le pseudo BalaBethany, a appris à programmer en interagissant en ligne avec ses pairs :

BalaBethany adore dessiner des personnages de dessins animés. Quand elle a commencé à utiliser Scratch, elle a tout naturellement programmé des histoires animées mettant en scène ses personnages. Elle a commencé à partager son projet sur le site Web de Scratch, et d’autres membres ont répondu positivement, en rédigeant des commentaires élogieux sur son projet (« Super ! », « Bon sang, j’adore !!! »…), tout en lui posant des questions concrètes et pragmatiques sur la manière dont elle avait réalisé certains effets (« Comment as-tu fait pour que le lutin devienne transparent ? »…). Encouragée, BalaBethany a alors créé et partagé régulièrement sur Scratch de nouveaux projets, tel celui ambitieux d’une simulation d’une série télé.

Régulièrement elle ajoutait un nouveau personnage à sa série et elle s’est un jour demandée si elle n’impliquerait pas toute la communauté Scratch dans le processus. Elle a alors créé et déposé un nouveau projet sur Scratch qui annoncait un « concours », demandant aux autres membres de la communauté de dessiner la sœur de l’un des personnages. Le projet listait des éléments qui devaient faire partie du nouveau personnage, comme Doit avoir des cheveux rouges ou bleus, merci de choisir et Doit avoir soit un chat ou une corne de bélier, ou un mélange des deux.

Le projet a reçu plus de 100 commentaires. L’un d’eux venait d’une membre de la communauté qui voulait bien participer au concours mais qui disait qu’elle ne savait pas dessiner des personnages de dessins animés. BalaBethany a alors pris le temps de produire un autre projet, un tutoriel pas à pas montrant en 13 étapes comment dessiner et colorier un personnage animé.

En une année, BalaBethany a programmé et partagé plus de 200 projets Scratch dans divers domaines (histoires, concours, tutoriaux, et bien d’autres). Aussi bien ses talents de programmatrice que ses talents artistiques se sont développés, et ses projets ont été très bien accueillis par la communauté Scratch, puisqu’elle a reçu pas moins de 12 000 commentaires.

L’un des groupes du MIT a également fondé le projet Club d’informatique, un réseau international d’une centaine de centres aérés où des enfants défavorisés âgés de 10 à 18 ans peuvent exprimer leur créativité en utilisant les nouvelles technologies. Avec l’aide d’un animateur, les participants créent des histoires interactives, des clips, et construisent des robots. L’extrait suivant souligne comment la technologie peut aider les enfants à forger leur identité et à s’imposer comme membres à part entière d’un groupe :

Observons Mike Lee, qui a passé du temps au club informatique de Huston. Mike a commencé à venir au club après avoir quitté le lycée. Il était passionné par le dessin. Il remplissait des carnets les uns après les autres avec des personnages de dessin animé. Au club, Mike a développé une nouvelle méthode pour ses dessins. Pour commencer, il dessinait des croquis à la main en noir et blanc. Puis, il a scanné ses croquis et les a colorié à l’ordinateur.

Avec le temps, Mike a appris à utiliser des techniques informatiques plus complexes pour ses dessins. Les créations de Mike impressionnaient tout le monde au club, puis d’autres jeunes ont commencé à venir le voir pour avoir des conseils. Certains membres se sont ouvertement inspirés du style artistique de Mike. Bientôt, une collection de dessins « à la manière de Mike Lee » est paru dans le journal du club. « C’était assez flatteur », disait Mike.

Pour la première fois de sa vie, d’autres personnes faisaient attention à Mike. Il a commencé à ressentir un sentiment nouveau de responsabilité. Il a décidé de ne plus utiliser d’armes à feu dans ses dessins, pensant que cela pouvait avoir une mauvaise influence sur les plus jeunes membres du club. Mike explique : « Mon travail personnel concerne souvent la violence urbaine. Un de mes amis s’est fait tirer dessus et est décédé. Mais je ne veux pas amener ça ici. Les enfants ne comprennent pas forcément bien les armes ; ils pensent que c’est cool. Ils voient un combat, c’est naturel qu’ils veuillent aller voir. Ils ne comprennent pas. Ce sont juste des enfants. »

Mike s’est mis ensuite à travailler avec d’autres clubs sur des projects collaboratifs. Ensemble, ils ont créé une galerie d’art virtuelle sur le Web. Une fois par semaine, ils ont rencontré un artiste local qui a bien voulu encadrer le projet. Au bout d’un an, leur galerie virtuelle fut acceptée comme exposition au Siggraph, la première conférence mondiale des arts graphiques numériques. Cette expérience l’a porté vers de nouvelles techniques artistiques. Il a ajouté de plus en plus d’effets informatiques, et a entamé un travail sur des collages numériques combinant des photographies et du dessin, tout en conservant son style particulier. Avec le temps, Mike a exploré comment il pouvait utiliser son ses talents pour en faire une sorte de commentaire social et d’expression politique.

Pendant qu’il venait au club, Mike Lee a clairement appris beaucoup de choses dans le domaine de l’informatique et l’infographie. Mais il a également commencé à développer sa propre idée de l’enseignement et de l’apprentissage. « Au club, j’étais libre de faire ce que je voulais, d’apprendre ce que je voulais », disait Mike. « Si j’avais suivi des cours d’informatique dans une école, il y aurait eu trop de contraintes. Ici je pouvais créer en totale liberté.» Mike se rappelle — et apprécie — la manière dont les animateurs du club l’on accueilli quand il est arrivé au club. Ils lui ont demandé de dessiner un logo pour l’entrée du club. Ils n’ont jamais pensé à lui comme un « exclu du lycée » mais comme un créateur potentiel.

Après plusieurs années en tant que bénévole au club, Mike a obtenu une équivalence du Bac, puis a obtenu un emploi d’infographiste dans une entreprise de haute technologie près de Boston, concevant graphiquement les pages web, les catalogues et les brochures de la société.

L’expérience de Mike au club informatique illustre la puissance de l’interaction entre les gens ainsi que l’utilisation du numérique en apprentissage pour aider et encourager un débutant qui se sentait mal à l’aise dans son environnement scolaire traditionnel. Avec l’accès à la technologie et au réseau social du club informatique, Mike a appris à développer ses dons artistiques, à partager son savoir et son talent avec d’autres et à devenir un membre actif et créatif de la communauté.