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

Traduction Framalang : Ouve, merlin8282, Julius22, Sphinx, CoudCoud, lum’, goofy, peupleLà, Alpha, Peekmo, audionuma, lamessen

Rassembler les gens

Dave Neary

Dave Neary travaille sur des projets libres et open source depuis qu’il a découvert Linux en 1996. C’est un contributeur de longue date à GNOME et à GIMP. Il travaille à plein temps depuis 2007 pour aider des entreprises à se réconcilier avec les logiciels développés de façon communautaire. Durant cette période, il a travaillé sur divers projets dont OpenWengo, Maemo et Meego, qui étaient liés à de l’événementiel, à des méthodes de travail communautaires, à de la gestion de produits ainsi qu’à de la gestion d’outils d’analyse d’une communauté. Il s’est impliqué, en tant que bénévole, dans l’organisation du GUADEC, du Desktop Summit, du Libre Graphics Meeting, de la GIMP Conference, d’Ignite Lyon, de l’Open World Forum et de la MeeGo Conference.

L’une des choses les plus importantes que vous puissiez faire dans un projet lié au logiciel libre, à part écrire du code, c’est de rassembler les principaux contributeurs aussi souvent que possible. J’ai eu la chance de pouvoir organiser un certain nombre d’événements au cours de ces dix dernières années, mais aussi d’observer les autres et d’apprendre à leur contact pendant ce temps. Voici quelques-unes des leçons que j’ai apprises au cours du temps, grâce à cette expérience.

1. Le lieu

Le point de départ pour la plupart des réunions ou des conférences, c’est le lieu. Si vous réunissez un petit groupe (moins de dix personnes), il suffit bien souvent de choisir une ville et de demander à un ami qui possède une entreprise ou qui est professeur d’université de vous réserver une salle. Vous aurez sans doute besoin d’une organisation plus formelle dès qu’il y aura plus de monde à accueillir.

Si vous ne faites pas attention, le lieu de l’événement sera une grande source de dépenses et il vous faudra trouver l’argent correspondant quelque part. Mais si vous êtes futé, vous pouvez vous débrouiller pour obtenir assez facilement une salle gratuitement.

Voici quelques-unes des stratégies qu’il serait intéressant d’essayer :

• Intégrez-vous au sein d’un autre événement : le Linux Foundation Collaboration Summit, OSCON, LinuxTag, GUADEC et beaucoup d’autres conférences accueillent volontiers des ateliers ou des rencontres pour de plus petits groupes. Le GIMP Developers Conference en 2004 a été le premier rassemblement que j’ai organisé, et afin de ne pas avoir à subir les problèmes inhérents au fait de trouver la salle, une date qui convient à tout le monde et ainsi de suite, j’ai demandé à la GNOME Foundation si ça ne les dérangeait pas de nous laisser un peu d’espace lors de la GUADEC — et ils ont accepté. Tirez parti de l’organisation d’une conférence plus grande, et vous pourrez en plus assister à cette grande conférence par la même occasion !
• Demandez aux universités environnantes si elles n’ont pas des salles disponibles. Ça ne fonctionnera plus une fois que vous aurez dépassé une certaine taille, néanmoins, vous pouvez vous renseigner en particulier dans les universités dont certains chercheurs sont des membres du Linux User Group (LUG) [NdT : groupe d’utilisateurs de Linux] local. Ils peuvent en parler avec leur directeur de département afin de réserver un amphithéâtre et quelques salles de classe pour un week-end. Un grand nombre d’universités vous demanderont de faire un communiqué de presse et d’être mentionnées sur le site Web de la conférence, ce qui est un juste retour des choses. Le premier Libre Graphics Meeting s’est déroulé gratuitement à CPE Lyon et le GNOME Boston Summit a été accueilli gratuitement pendant des années par le MIT.
• Si le lieu de rendez-vous ne peut pas être gratuit, voyez si quelqu’un d’autre ne peut pas le financer. Lorsque votre conférence commence à accueillir plus de 200 personnes, la plupart des salles seront payantes. Héberger une conférence coûtera beaucoup d’argent à celui qui prête les locaux, et c’est une part importante dans le modèle économique des universités que d’organiser des conférences lorsque les étudiants sont partis. Mais ce n’est pas parce que le centre de conférence ou l’université ne peut pas vous accueillir gratuitement que cela signifie que vous devez être la personne qui paye. Les collectivités territoriales aiment bien être impliquées lorsqu’il s’agit d’organiser des événements importants dans leur région. Le GUADEC à Stuttgart, le Gran Canaria Desktop Summit et le Desktop Summit à Berlin ont tous été financés par la région d’accueil en ce qui concerne la salle. S’associer avec une région présente un avantage supplémentaire : elles ont souvent des liens avec les entreprises et la presse locale, ce qui représente des ressources que vous pouvez utiliser afin d’obtenir de la visibilité et peut-être même des sponsors pour votre conférence.
• Faites un appel d’offres : en incitant les groupes qui souhaitent héberger la conférence à déposer une offre, vous les incitez aussi à trouver une salle et à discuter avec les partenaires locaux avant de vous décider sur l’endroit où aller. Vous mettez aussi les villes en concurrence, et comme pour les candidatures aux Jeux Olympiques, les villes n’apprécient pas de perdre les compétitions auxquelles elles participent !

2. Le budget

Les conférences coûtent de l’argent. Ce qui peut coûter le plus cher pour une petite rencontre, ce sont les frais de déplacement des participants. Pour une conférence plus importante, les principaux coûts seront l’équipement, le personnel et la salle. Chaque fois que j’ai dû réunir un budget pour une conférence, mon approche globale a été simple :

• décider de la somme d’argent nécessaire pour réaliser l’événement ;
• collecter les fonds jusqu’à atteindre ce montant ;
• arrêter la collecte et passer aux étapes suivantes de l’organisation.

Lever des fonds est une chose difficile. On peut vraiment y passer tout son temps. Au bout du compte, il y a une conférence à préparer, et le montant du budget n’est pas la préoccupation principale de vos participants.

Rappelez-vous que votre objectif principal est de réunir les participants du projet afin de le faire avancer. Alors, obtenir des réponses de participants potentiels, organiser le logement, la salle, les discours, la nourriture et la boisson, les activités sociales et tous les autres aspects de ce à quoi les gens s’attendent lors d’un événement… tout cela est plus important que la levée de fonds.

Bien sûr, de l’argent est nécessaire pour être capable d’organiser tout le reste. Alors, trouver des sponsors, décider de leurs niveaux de participation et vendre la conférence est un mal nécessaire. Mais une fois que vous avez atteint le montant nécessaire pour la conférence, vous avez vraiment mieux à faire.

Il existe quelques sources potentielles de financement pour préparer une conférence — combiner ces sources semble, selon moi, la meilleure des façons pour augmenter vos recettes.

• les participants : même si c’est un sujet de controverse dans de nombreuses communautés, je crois qu’il est tout à fait justifié de demander aux participants de contribuer en partie aux coûts de la conférence. Les participants profitent des installations ainsi que des événements sociaux et tirent parti de la conférence. Certaines communautés considèrent la participation à leur événement annuel comme une récompense pour services rendus ou comme une incitation à faire du bon travail dans l’année à venir. Mais je ne crois pas que ce soit une façon pérenne de voir les choses. Pour les participants à une conférence, il y a plusieurs façons de financer l’organisation de celle-ci :
  1. les droits d’inscription : c’est la méthode la plus courante pour obtenir de l’argent de la part des participants à la conférence. La plupart des conférences communautaires demandent un montant symbolique. J’ai vu des conférences qui demandaient un droit d’entrée de 20 à 50 euros ; et ça ne posait aucun problème à la plupart des gens de payer cela. Un règlement d’avance a l’avantage supplémentaire de réduire massivement les désistements parmi les gens qui vivent à proximité. Les gens accordent plus d’importance à la participation à un événement leur coûtant dix euros qu’à un autre dont l’entrée est gratuite, même si le contenu est identique,
  2. les dons : ils sont utilisés avec beaucoup de succès par le FOSDEM. Les participants reçoivent un ensemble de petits cadeaux fournis par les sponsors (livres, abonnements à des magazines, T-shirts) en échange d’un don. Mais ceux qui le souhaitent peuvent venir gratuitement,
  3. la vente de produits dérivés : votre communauté serait peut-être plus heureuse d’accueillir une conférence gratuite et de vendre des peluches, des T-shirts, des sweats à capuche, des mugs et d’autres produits dérivés afin de récolter de l’argent.? Attention ! D’après mon expérience, on peut s’attendre à obtenir moins de bénéfices de la vente de produits dérivés qu’on n’en obtiendrait en offrant un T-shirt à chaque participant ayant payé un droit d’inscription,
• les sponsors : les publications dans les médias accepteront généralement un « partenariat de presse » — en faisant de la publicité pour votre conférence dans leur magazine papier ou sur leur site Web. Si votre conférence est déclarée comme émanant d’une association à but non-lucratif pouvant accepter des dons avec des déductions d’impôts, proposez à vos partenaires dans la presse de vous facturer pour les services et de vous donner ensuite une subvention de partenariat séparée pour couvrir la facture. Le résultat final est identique pour vous. Mais il permettra à la publication de compenser l’espace qu’elle vous vend par des réductions d’impôts. Ce que vous souhaitez vraiment, ce sont des parrainages en liquide. Comme le nombre de projets de logiciels libres et les conférences se sont multipliés ces dernières années, la compétition pour les parrainages en liquide s’est intensifiée. Afin de maximiser vos chances d’atteindre le budget que vous vous êtes fixé, voici les actions que vous pouvez entreprendre :
  1. une brochure de la conférence : pensez à votre conférence comme un produit que vous vendez. Que représente-t-elle, quelle attention attire-t-elle, à quel point est-elle importante pour vous, pour vos membres, pour l’industrie et au-delà ? Qu’est ce qui a de la valeur pour votre sponsor ? Vous pouvez vendre un contrat de parrainage sur trois ou quatre éléments différents : peut-être que les participants à votre conférence constituent une audience cible de grande valeur pour le sponsor, peut-être (en particulier pour les conférences de moindre importance) que les participants ne sont pas ce qui est important mais plutôt la couverture dont bénéficiera la conférence dans la presse internationale ou bien peut-être que vous vendez à l’entreprise le fait que la conférence améliore un élément logiciel dont elle dépend. En fonction du positionnement de la conférence, vous pouvez lister les sponsors potentiels. Vous devriez avoir une brochure de parrainage que vous pourrez leur envoyer. Elle devra contenir une description de la conférence, un argumentaire de vente expliquant pourquoi il est intéressant pour l’entreprise de la parrainer, éventuellement des coupures de presse ou des citations de participants à des éditions antérieures disant à quel point votre conférence est géniale et, finalement, la somme d’argent que vous recherchez,
  2. des niveaux de parrainage : ils devraient être fixés en fonction de la somme que vous voulez lever. Vous devriez attendre de votre sponsor le plus important qu’il vous fournisse entre 30 et 40 % du budget total de la conférence, pour une conférence de moindre importance. Si vous êtes chanceux et que votre conférence attire de nombreux sponsors, cela peut s’élever à seulement 20 %. Pour vos estimations, visez un tiers. Ceci signifie que si vous avez décidé que vous avez besoin de 60 000 euros, vous devriez alors mettre votre niveau de sponsor principal à 20 000 euros et tous les autres niveaux en conséquence (disons 12 000 euros pour le deuxième niveau et 6 000 pour le troisième). Pour les conférences de moindre importance et les rencontres, le processus peut être légèrement plus informel. Mais vous devriez toujours penser au processus entier comme un argumentaire de vente,
  3. un calendrier : la plupart des entreprises ont un cycle budgétaire soit annuel, soit semestriel. Si vous émettez votre demande à la bonne personne au bon moment, vous pourriez alors avoir une discussion bien plus aisée. Le meilleur moment pour soumettre des propositions de parrainage d’une conférence estivale est aux environs d’octobre ou de novembre de l’année précédente, lorsque les entreprises finalisent leur budget annuel. Si vous manquez cette fenêtre, tout n’est pas perdu. Mais tout parrainage que vous obtenez viendra des budgets de fonctionnement qui tendent à être maigres et qui sont gardés précieusement par leurs propriétaires. Sinon, vous pouvez obtenir un engagement de parrainage en mai pour votre conférence de juin, à la fin du processus budgétaire du premier semestre — ce qui est tardif dans la préparation,
  4. approcher les bonnes personnes : je ne vais pas enseigner l’art de la vente à qui que ce soit mais mon secret personnel dans les négociations avec les grandes organisations est de devenir ami avec des personnes à l’intérieur de ces organisations et de me forger une impression sur l’origine potentielle du budget pour mon événement. Votre ami ne sera probablement pas la personne qui contrôle le budget mais l’avoir à vos cotés est une chance d’avoir un allié au sein de l’organisation. Il fera en sorte que votre proposition soit mise devant les yeux de la personne en charge du budget. Les grandes organisations peuvent être aussi dures qu’une noix est dure à craquer, mais les projets de logiciels libres ont souvent des amis dans les hautes sphères. Si vous avez vu le directeur technique ou le PDG d’une entreprise classée au Fortune 500 parler de votre projet dans un article de journal, n’hésitez pas à lui envoyer quelques mots en évoquant le fait que, quand le temps sera venu de financer cette conférence, une note personnelle demandant qui est la meilleure personne à contacter fera des merveilles. Souvenez-vous que votre objectif n’est pas de vendre votre contact personnel mais de le changer en un défenseur de votre cause à l’intérieur de l’organisation et de créer la chance de, plus tard, vendre la conférence à la personne responsable du budget,
• Souvenez-vous aussi, en vendant des contrats de parrainage, que tout ce qui vous coûte de l’argent pourrait faire partie d’un contrat de parrainage. Certaines entreprises offriront des tours de cou aux participants, la pause café, la glace de l’après-midi ou bien un événement social. Ce sont de bonnes occasions de parrainage et vous devriez exprimer clairement, dans votre brochure, tout ce qui se déroule. Vous devriez aussi définir un budget prévisionnel pour chacun de ces évènements lorsque vous écrivez le brouillon de votre budget.

3. Contenu

Le contenu d’une conférence est son élément le plus important. Des événements différents peuvent traiter différemment d’un même contenu — certains événements invitent une grande partie de leurs intervenants, tandis que d’autres comme GUADEC et OSCON font des appels à propositions et choisissent les interventions qui rempliront les salles.

La stratégie que vous choisirez dépendra beaucoup de la nature de l’événement. Si l’événement existe depuis une dizaine d’années, avec un nombre de participants toujours croissant, faire un appel à articles est une bonne idée. Si vous êtes dans votre première année, et si les personnes ne savent vraiment pas quoi faire de l’événement, alors donnez le ton en invitant de nombreux orateurs, aidant ainsi les gens à comprendre votre objectif.

Pour Ignite Lyon l’an dernier, j’ai invité environ 40 % des orateurs pour le premier soir (et j’ai souvent dû les harceler pour qu’ils me proposent une intervention). Les 60 % restants sont venus via un formulaire de candidature. Pour le premier Libre Graphics Meeting, en dehors des présentations éclairs, je pense avoir d’abord contacté chaque orateur, à l’exception de deux d’entre eux. Maintenant que l’événement en est à sa 6^e année, il existe un processus d’appel à contributions qui fonctionne plutôt bien.

4. Le programme

Il est difficile d’éviter de mettre en parallèle des exposés attrayants pour les mêmes personnes. Dans chaque conférence, vous pouvez entendre des personnes qui voulaient assister à des conférences se déroulant en même temps, sur des sujets similaires.

Ma solution pour la programmation des conférences est très simple, mais elle fonctionne dans mon cas. Des post-it de couleur, avec une couleur différente pour chaque thème, et une grille vide. Le tour est joué. Écrivez les titres des exposés (un par post-it), ajoutez les quelques contraintes que vous avez pour l’orateur, puis remplissez la grille.

Mettre le programme en-dehors de l’ordinateur, et dans des objets réels, permet de voir très facilement les conflits, d’échanger les conférences aussi souvent que vous voulez, et de le publier ensuite sur une page Web quand vous en êtes satisfait.

J’ai utilisé cette technique avec succès pour GUADEC 2006 et Ross Burton l’a réutilisée avec succès en 2007

.

5. Les fêtes

Les fêtes sont un compromis à trouver. Vous voulez que tout le monde s’amuse, et s’éclater jusqu’au petit matin est une partie très importante quand on participe à une conférence. Mais la fréquentation matinale souffre après une fête. Ayez pitié du pauvre membre de la communauté devant se tirer hors du lit après trois heures de sommeil pour aller parler devant quatre personnes à 9 heures du matin après la fête.

Certaines conférences ont trop de fêtes. C’est super d’avoir la possibilité de se saouler avec des amis chaque nuit. Mais ça n’est pas génial de vraiment le faire chaque nuit. Rappelez-vous du but de la conférence : vous voulez stimuler l’avancement de votre projet.

Je préconise une grande fête, et une plus petite, au cours de la semaine. En-dehors de ça, les personnes seront tout de même ensemble et passeront de bons moments, mais ce sera à leurs frais, ce qui fait que chacun restera raisonnable.

Avec un peu d’imagination, vous pouvez organiser des événements qui n’impliquent pas l’utilisation de musique forte et d’alcool. D’autres genres d’événements sociaux peuvent faire l’affaire, et même être plus amusants.

Au GUADEC, nous organisons un tournoi de football depuis quelques années. Lors du sommet OpenWengo en 2007, nous avions embarqué les personnes pour une balade en bateau sur la Seine puis nous étions ensuite montés sur un manège du XIX^e siècle. Faire manger les gens ensemble est un autre moyen de nouer des liens. J’ai de très agréables souvenirs de repas de groupe lors de nombreuses conférences. À la conférence annuelle de KDE, l’Akademy, il y a traditionnellement une grande journée de sortie durant laquelle les personnes vont ensemble à un pique-nique, quelques activités simples de plein air, une promenade en bateau, un peu de tourisme ou quelque chose de similaire.

6. Les coûts supplémentaires

Attention à ces dépenses imprévues ! Une conférence dans laquelle j’étais impliqué, et où le lieu de réunion était « sponsorisé à 100 % » nous a laissé une note de 20 000 euros pour les coûts de main-d’œuvre et d’équipement. Oui, le lieu était sponsorisé, mais la mise en place des tables et des chaises, ainsi que la location des écrans, des vidéoprojecteurs et de tout le reste ne l’était pas. Au bout du compte, j’ai estimé que nous avions utilisé seulement 60 % de l’équipement que nous avions payé.

Tout ce qui est fourni sur place est extrêmement coûteux. Une pause-café peut coûter jusqu’à 8 euros par personne pour un café et quelques biscuits, de l’eau en bouteille pour les conférenciers coûte quatre euros par bouteille, etc. La location d’un rétroprojecteur et de micros pour une salle peut coûter 300 euros ou plus pour une journée, selon que le propriétaire exige ou non que l’équipement audio-vidéo soit manipulé par son propre technicien.

Quand vous traitez avec un lieu commercial, soyez clair dès le départ sur ce pour quoi vous payez.

Les détails sur place

J’aime les conférences attentives aux petits détails. En tant qu’orateur, j’aime quand quelqu’un me contacte avant la conférence pour m’avertir qu’il me présentera. Que souhaiterais-je qu’il dise ? C’est rassurant de savoir que, quand j’arriverai, il y aura un micro sans fil et quelqu’un qui peut aider à l’ajuster.

Faire attention à tous ces détails nécessite de nombreux volontaires, et ça nécessite quelqu’un pour les organiser avant et pendant l’événement. Il faut passer beaucoup de temps à parler à l’équipe sur place, plus particulièrement aux techniciens audio/vidéo.

Lors d’une conférence, le technicien audio-vidéo avait prévu de basculer manuellement l’affichage vers un économiseur d’écran à la fin d’une conférence. Au cours d’une session de mini-conférences, nous nous sommes retrouvés dans une situation burlesque quand, après le premier conférencier, j’ai interverti l’ordre de passage : au moment où la présentation suivante s’affichait sur mon portable, nous avions toujours l’économiseur sur le grand écran. Personne n’avait parlé avec le technicien de la régie pour lui expliquer le format de la présentation ! Et c’est comme ça qu’on a fini par avoir pas moins de quatre spécialistes de Linux à s’occuper de l’ordinateur portable qui vérifiaient les connexions en psalmodiant divers mantras Xrandr, qui s’efforçaient de remettre en marche le rétroprojecteur au-dessus de nos têtes ! Nous avons fini par changer d’ordinateur portable, le technicien de la régie a compris de quel type de session il s’agissait, et ensuite tout s’est fort bien passé — la plupart des gens concernés ont accusé mon portable.

Gérer une conférence, ou parfois une plus petite rencontre, prend du temps, et nécessite beaucoup d’attention aux détails, qui pour la plupart ne seront jamais remarqués par les participants. Et je n’ai même pas évoqué des choses comme les banderoles et les affiches, la création du graphisme, la gestion de la presse ou d’autres joyeusetés qui vont de pair avec l’organisation d’une conférence.

Le résultat final est en revanche particulièrement gratifiant. Une étude que j’ai menée l’année dernière sur le projet GNOME a montré qu’il y a eu une forte augmentation de la productivité sur tout le projet juste après notre conférence annuelle et un grand nombre de membres de notre communauté mentionnent la conférence comme ayant été, pour eux, le point culminant de l’année.

Lors du tout récent SXSW, Sir Tim Berners-Lee, répondant à une question, s’est montré favorable à l’introduction de DRM dans le HTML5, c’est-à-dire directement dans le code des pages Web.

Ceci a déçu beaucoup de monde, à commencer par Cory Doctorow qui lui a répondu dans les colonnes du Guardian, traduit ci-dessous pour nos soins.

Ce que j’aurais souhaité que Tim Berners-Lee comprenne au sujet des DRM

What I wish Tim Berners-Lee understood about DRM

Cory Doctorow – 12 mars 2013 – The Guardian (Blog Tchnology)
(Traduction Framalang : catalaburro, Alpha, Alpha, lum’, Tito, goofy, peupleLà, lamessen, penguin + anonymes)

Ajouter des DRM au standard HTML aura des répercussions importantes qui seront incompatibles avec les règles fondamentales du W3C.

À la suite de son discours d’introduction au récent SXSW, l’inventeur du Web Tim Berners-Lee a répondu à une question concernant le projet controversé d’ajouter des DRM à la prochaine version du HTML. Le standard HTML5, qui est en ce moment en débat au W3C (World Wide Web Consortium), est le dernier en date des champs de bataille dans la longue guerre pour la conception des ordinateurs personnels. Berners-Lee a soutenu ce projet en prétendant que, sans les DRM, une part croissante du Web serait verrouillée dans des formats comme le Flash, impossibles à lier et à soumettre à la recherche.

Certains membres de l’industrie du divertissement ont longtemps entretenu le doux rêve d’ ordinateurs conçus pour désobéir à leurs propriétaires, dans une stratégie globale de maximisation des profits qui s’appuie sur la possibilité de vous faire payer pièce après pièce pour avoir le droit d’utiliser les fichiers stockés sur vos disques durs.

Il est notoire que l’industrie a réussi à convaincre les fabricants de lecteurs de DVD d’ajouter une limitation au lecteur pour vous empêcher de lire un DVD sur un continent si vous l’avez acheté dans un autre. Pour que cela fonctionne, les lecteurs de DVD ont dû être conçus pour cacher les programmes qui les faisaient tourner. Ainsi les propriétaires de lecteurs de DVD ne pouvaient tout simplement pas arrêter la fonction de « vérification de zone ». Les lecteurs devaient aussi être conçus pour cacher des fichiers à leurs propriétaires, de telle manière que les utilisateurs ne puissent pas trouver le fichier contenant la clé de déchiffrement afin de l’utiliser pour déverrouiller le DVD sur d’autres lecteurs, ceux qui ne vérifieraient pas la compatibilité de zone du DVD.

Deux questions importantes découlent de cet exemple historique. Tout d’abord, cela a-t-il fonctionné ? et deuxièmement, pourquoi diable les fabricants ont ils été d’accord avec ces limitations ? Ces deux questions sont importantes à poser ici.

Est-ce que le zonage géographique a fonctionné ? Pas du tout. Après tout, cacher des fichiers et des processus dans l’ordinateur que le « méchant » peut tout à fait embarquer avec lui dans un labo ou au bureau est complètement vain. Si Berners-Lee pense qu’ajouter des secrets aux navigateurs web auxquels les possesseurs d’ordinateurs ne pourront accéder permettra d’une quelconque manière de créer les marchés dont l’industrie du divertissement a soi-disant besoin pour créer de nouveaux modèles économiques, il se trompe.

Plus important encore : pourquoi les fabricants sont-ils d’accord pour ajouter des restrictions à leurs matériels ? Le zonage est le contraire d’une fonctionnalité, un « produit » qui n’a pas pour but d’être vendu. Vous ne pouvez pas vendre plus de lecteurs DVD en ajoutant un autocollant qui dit : « Nouvelle version, avec des restrictions par zones géographiques ! »

Les pièges du brevet

En clair, c’est l’industrie qui a établi un besoin légal pour l’établissement des DRM sur les lecteurs DVD. Lorsque les organismes à l’origine des DRM se rassemblent, ils cherchent à identifier un « lien de propriété intellectuelle », bien souvent un brevet. Si un brevet entre en jeu lors du décodage d’un format de fichier, alors le brevet peut être lié à l’application des termes de la licence, ce qui peut être utilisé pour contraindre les fabricants.

En d’autres termes, si un brevet (ou des brevets) peut être inclus dans le système de décodage des DVD, il est possible de menacer les fabricants d’un procès pour violation de brevet,à moins qu’ils n’achètent une licence d’utilisation. Les licences de brevet sont gérées par la Licensing Authority (LA) (NdT : Consortium regroupant les détenteurs de brevets sur la technologie en question, ici la MPEG-LA) qui crée des normes de contrat de licence. Ces termes incluent toujours une liste de fonctionnalités que les fabricants ne doivent pas implémenter (par exemple il ne leur est pas possible d’ajouter une fonctionnalité « sauvegarder sur un disque dur » à un lecteur DVD); et une liste de fonctionnalités négatives que les fabricants doivent implémenter (par exemple l’ajout obligatoire d’une fonction : « vérifier la zone » au lecteur).

Par ailleurs, tous les accords de licence de DRM s’accompagnent d’un ensemble de règles de « robustesse » qui incite les fabricants à concevoir leur produit de façon à ce que leur propriétaire ne puisse ni voir ce que font ces DRM ni les modifier. Cela a pour but d’empêcher que le possesseur d’un dispositif n’en reconfigure les propriétés pour faire des choses interdites (« sauvegarder sur le disque ») ou pour ignorer des choses obligatoires (« vérifier la région »).

Ajouter les DRM au standard HTML aura des répercussions étendues qui sont incompatibles avec les règles les plus importantes du W3C et avec les principes qui tiennent particulièrement à cœur à Berners-Lee.

Par exemple, le W3C a fait avancer les organismes de normalisation en insistant sur le fait que les standards ne devaient pas être gênés par les brevets. Lorsque des membres du W3C détiennent des brevets sur une partie d’un standard, ils doivent promettre à tous les utilisateurs de fournir une licence qui ne possède pas de conditions trop contraignantes. Cependant, les DRM nécessitent des brevets ou des éléments sous licence dont le seul objectif est d’ajouter des conditions contraignantes aux navigateurs.

La première de ces conditions – la « robustesse » contre les modifications de l’utilisateur final – est une exclusion totale de tous les logiciels libres (ces logiciels qui, par définition, peuvent être modifiés par leurs utilisateurs). Cela signifie que les deux technologies de navigateurs web les plus populaires, WebKit (utilisé avec Chrome et Safari) et Gecko (utilisé avec Firefox et ses navigateurs apparentés), pourraient légalement se voir interdire d’être intégré dans l’une de ces « normes » qui sortiraient du W3C.

Copie moi si tu peux

Plus encore, les DRM sont parfaitement inefficaces pour empêcher la copie. Je suspecte Berners-Lee d’en être parfaitement conscient. Quand les geeks minimisent les craintes autour des DRM, ils disent souvent des choses telles que : « He bien, je peux les contourner et de toute façon ils reviendront à la raison tôt ou tard vu que cela ne fonctionne pas, non ? ». Chaque fois que Berners-Lee raconte l’histoire des débuts du Web, il insiste sur le fait qu’il a pu inventer le Web sans demander la moindre permission. Il utilise cela comme une parabole pour expliquer l’importance d’un Internet ouvert et neutre. Mais il échoue à comprendre que la raison d’être des DRM est d’obliger à demander une permission pour innover.

Car limiter la copie n’est qu’une raison superficielle à l’ajout de DRM à une technologie. Les DRM échouent complètement lorsqu’il s’agit d’empêcher la copie, mais sont remarquablement efficaces pour éviter toute innovation. En effet les DRM sont couverts par les lois anti-contournement telles que la célèbre DMCA de 1998 (US Digital Millennium Copyright Act) et l’EUCD de 2002 (EU Copyright Directive) ; chacune d’elle fait du contournement de DRM un crime, même si vous n’enfreignez aucune autre loi. Concrètement, cela signifie que vous devez demander la permission à une autorité de licence de DRM pour ajouter ou modifier n’importe quelle fonctionnalité, ce que les termes de la licence vous interdisent de faire.

Comparons les DVD aux CD. Les CD n’avaient pas de DRM, il était donc légal d’inventer des technologies comme l’iPod ou iTunes qui extrayaient, encodaient et copiaient la musique pour un usage privé. Les DVD avaient des DRM, il était donc illégal d’en faire quoi que ce soit de plus et depuis presque 20 ans qu’ils sont apparus, aucune technologie légale n’a vu le jour sur le marché pour faire ce que iTunes et l’iPod font depuis 2001. Une entreprise a essayé de lancer un jukebox primitif à DVD combiné à un disque dur et fut poursuivie pour cette activité commerciale. 20 ans de DVD, zéro innovation. Bon, les DRM n’ont pas empêché les gens de créer des copies illégales de DVD (bien entendu !), mais elles ont complètement empêché l’émergence sur le marché de tout produit légal et innovant, et nous ne sommes pas près d’en voir la fin.

Prêts à vous faire les poches

C’est ce vers quoi le W3C essaie de faire tendre le Web. Et Berners-Lee, avec ses remarques, en prend la responsabilité. Un état où chaque amélioration est vue comme une occasion d’instaurer un péage. Un Web construit sur le modèle économique de l’infection urinaire : plutôt que d’innover dans un flot sain, chaque nouvelle fonctionnalité doit venir d’une petite goutte contractée et douloureuse : quelques centimes si vous voulez la lier à un temps spécifique de la vidéo, encore quelques centimes si vous souhaitez intégrer un lien provenant de la vidéo dans une page web, encore plus si vous souhaitez mettre la vidéo sur un autre appareil ou la décaler dans le temps, et ainsi de suite.

Le W3C étant l’organisme principal qui normalise le Web, son action repose sur une confiance énorme à la fois sacrée et significative. Le futur du Web est le futur du monde, car tout ce que nous faisons aujourd’hui implique le net et ce sera tout aussi nécessaire pour tout ce que nous ferons demain. À présent, il souhaite brader cette confiance, uniquement parce que les principaux fournisseurs de contenu verrouilleront leur « contenu » en utilisant Flash s’ils ne parviennent pas à obtenir de veto sur l’innovation issue du Web. Cette menace n’est pas nouvelle : les grands studios avaient promis de boycotter la télévision numérique américaine si elle ne rendait pas les DRM obligatoires. Les tribunaux américains ont refusé de leur accorder cette aubaine, et pour autant, la télévision numérique continue de fonctionner (si seulement Otcom et la BBC avaient tenu compte de cet exemple avant de vendre la télévision britannique aux studios américains en ce qui concerne nos propres normes de télévision numérique HD).

Flash est déjà hors course. Comme Berners-Lee vous le dira lui-même, la présence de plate-formes ouvertes, où l’innovation n’a pas besoin d’autorisation, est la meilleure façon d’inciter le monde à se connecter à vous. Un Web ouvert crée et distribue tant de valeur que chacun s’est mis à l’utiliser, délaissant ainsi les écosystèmes contrôlés semblables à Flash, entouré d’AOL et autres systèmes défaillants. Les gros studios ont plus besoin du Web que le Web n’a besoin d’eux.

Le W3C a le devoir d’envoyer au diable les colporteurs de DRM, tout comme les tribunaux américains l’ont fait lors de l’affaire de la TV numérique. Il n’y a pas de marché pour les DRM, pas de cause d’utilité publique qui justifie l’octroi d’un droit de veto à d’obscurs géants des médias qui ne voient pas plus loin que le bout de leur nez et qui rêvent d’un monde où chaque fois que vous cliquez, vous passez à la caisse et où la difficulté d’utilisation est quelque chose qui arrivent aux autres et pas à eux.

Crédit photo : Etech (Creative Commons By)

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

Traduction Framasoft : Miki, Vilnus Atyx, Sphinx, peupleLà, Goofy, tcit, Julius22, Garburst, Cyrille L., lerouge, Lycoris, vvision, lamessen

Comment ne pas lancer une communauté

Robert Kaye

Robert Kaye associe son amour de la musique et de l’open source dans l’encyclopédie de musique ouverte MusicBrainz. Robert a créé et dirige la MetaBrainz Foundation, une organisation à but non-lucratif basée en Californie, dans la continuité d’un travail de longue haleine pour améliorer l’expérience de la musique numérique. Au-delà du hack pour MusicBrainz, Robert recherche des festivals intéressants comme le Burning Man et des projets périphériques tels que bidouiller des robots pour préparer des cocktails. Comme il est invariablement couronné d’une chevelure aux vives couleurs, vous n’aurez aucun mal à le reconnaître dans une foule.

En 1998, je travaillais pour Xing Technology à San Luis Obispo et j’étais à fond sur notre nouveau projet AudioCatalyst. C’était l’un des premiers programmes d’extraction de MP3 intégré utilisant la base de données CDDB. Il s’agit de la base de données de CD qui permet à chaque lecteur de trouver le titre et la composition de tout CD. Si le CD n’est pas enregistré, on peut saisir les données afin que la prochaine personne qui en a besoin puisse s’en servir. J’adorais ce projet collaboratif en ligne et j’y ai enregistré des centaines de CD en quelques années.

Un jour, il nous a été annoncé que CDDB avait été achetée par Escient, une société qui deviendrait GraceNote par la suite. La base de données CDDB avait été privatisée, de sorte que plus personne ne pouvait la télécharger dans son intégralité ! Pour parachever le tout, Escient ne dédommagea aucun des contributeurs pour leurs efforts. En manœuvrant ainsi, ils arnaquaient le grand public. J’étais plutôt furieux de cette décision et je le suis encore aujourd’hui.

Plus tard dans la semaine, lors d’une fête avec des amis, je me plaignais de ce qui était en train de se passer et expliquais à quel point j’étais mécontent. Mon ami Kevin Murphy me dit : « Pourquoi tu ne démarrerais pas ton propre projet open source pour faire concurrence à ces enfoirés ? »

Quelques semaines plus tard, je finissais de travailler pour Xing et j’avais quelques semaines de temps libre avant de commencer chez EMusic. Je décidai d’apprendre le Perl et la programmation web en autodidacte et de démarrer la création de CD Index, un projet sans compatibilité et sans infraction avec CDDB. J’ai bidouillé le projet pendant cette pause mais l’ai rapidement oublié lorsque je suis devenu membre du projet FreeAmp chez EMusic.

C’est alors que Slashdot demanda, en mars 1999, quelle solution open source allait remplacer CDDB. J’ai passé le reste de la journée et la majeure partie de la nuit à finir CD Index et à le déployer. J’ai soumis un billet sur Slashdot parlant de mon projet (1) et il fut mis en ligne rapidement. Comme prévu, des centaines de geeks se manifestèrent en quelques minutes si bien que mon serveur tomba et rendit l’âme.

Les masses de gens qui arrivèrent commencèrent immédiatement à gueuler pour que les choses se fassent. Il n’y avait même pas encore de liste de diffusion ou de logiciel de suivi de problèmes ; ils insistèrent pour en avoir tout de suite. Comme j’étais novice dans l’open source, je ne savais pas vraiment ce qui était nécessaire ou non pour lancer un tel projet, j’ai fait comme les gens le demandaient. Les protestations reprirent de plus belle et davantage de gens encore insistèrent pour que je ferme le service étant donné qu’il n’était pas parfait. Mais même au milieu de ce vaste bazar, nous avons reçu plus de 3 000 soumissions de CD au cours des premières 24 heures.

Une fois que les choses furent calmées, il y avait encore beaucoup de gens qui rouspétaient. Greg Stein déclara qu’il allait écrire une meilleure version immédiatement. Mike Oliphant, l’auteur de Grip, annonça qu’il allait également travailler à une nouvelle version. Alan Cox vint et proclama que les bases de données SQL n’y suffiraient pas et que je devais utiliser DNS pour créer un meilleur service de recherche de CD. — Hein, quoi ? J’étais très mécontent de la communauté qui grandissait autour du billet publié sur Slashdot. Je ne voulais pas d’un lieu où les gens se manquent de respect et où certains se croient permis de gueuler encore plus fort pour obtenir ce qu’ils veulent. Je perdis rapidement tout intérêt pour le projet et CD Index déclina. Les autres projets que des personnes avaient promis de commencer (à l’exception de FreeDB) ne prirent jamais forme.

Alors, quand la bulle du point com a éclaté, j’ai eu besoin de réfléchir à ce que j’allais faire ensuite. Il était clair que mon boulot chez EMusic n’avait rien de sûr ; je continuais à conduire un roadster Honda S2000, ma voiture trophée de l’époque point com. Avec les traites de la voiture qui doublaient mon loyer, je devais décider : soit mener ma propre entreprise et vendre ma voiture de rêve, soit déménager à Bay Area (San Francisco) et travailler sur le rêve de quelqu’un d’autre, si jamais je parvenais à y trouver un travail. Je décidai que le plus intéressant serait de travailler sur une encyclopédie musicale complète construite par les utilisateurs. Je vendis la S2000 et me concentrai pour commencer à travailler sur une nouvelle mouture de CD Index.

Au cours d’une autre soirée, le nom MusicBrainz me vint et j’enregistrai le nom de domaine pendant la fête. Le jour suivant, motivé par le nouveau nom du projet, je commençai à bidouiller sérieusement et, à l’automne 2000, je lançai musicbrainz.org. Lancer n’est pas le bon mot, ici — je mis le site en place et me demandai alors comment éviter une nouvelle communauté de gosses hystériques venant de Slashdot. Je n’importai jamais de données depuis CD Index, ni ne mentionnai MusicBrainz sur les listes de diffusion de CD Index. Je me suis simplement éloigné du projet CD Index ; je ne voulais plus rien avoir à faire avec celui-ci. À la fin, j’ai décidé d’ajouter un simple bouton à la page web de FreeAmp qui mentionnait MusicBrainz.

Et une chose très étonnante s’est produite : des gens sont venus jeter un coup d’œil au projet. C’était seulement quelques personnes au début, mais quand quelqu’un me signalait quelque chose, je commençais une conversation et recueillais autant de retours d’informations que possible. J’améliorais le logiciel grâce à ces retours. J’ai aussi imposé un ton de respect sur les listes de discussion et, à chaque fois que quelqu’un était irrespectueux, j’intervenais et haussais le ton.

Mes efforts concentrèrent le projet vers son amélioration. Je l’ai fait pendant trois ans avant qu’il ne devienne clair que cette approche était efficace. La base de données croissait régulièrement et la qualité des données passa d’exécrable à bonne en quelques années.

Les bénévoles, ça va ça vient, mais je suis la colonne vertébrale du projet, c’est toujours moi qui donne le la et sa direction à l’ensemble. Aujourd’hui, nous avons une association à but non-lucratif avec 3,25 employés dans quatre pays, Google, la BBC et Amazon comme clients et notre bilan financier est bon. Je ne pense pas que cela aurait pu se produire avec la communauté CD Index.

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

Traduction Framalang : lamessen, Sky, Kalupa, ga3lig, Wxcafe, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, peupleLa, Julius22

La Voie des tests conduit à la Lumière

Jonathan “Duke” Leto

Jonathan Leto, dit « Le Duc » est un développeur de logiciel, un mathématicien dont les travaux sont publiés, un ninja de Git et un passionné de cyclisme qui vit à Portland, en Oregon. C’est l’un des développeurs principaux de la machine virtuelle Parrot et le fondateur de Leto Labs LLC.

Lorsque j’ai commencé à m’impliquer dans le logiciel libre et open source, je n’avais aucune idée de ce que pouvaient être les tests ni de leur importance. J’avais travaillé sur des projets personnels de programmation auparavant, mais la première fois que j’ai réellement travaillé sur un projet collaboratif (c’est-à-dire en faisant un peu de commit) c’était pour Yacas, acronyme de Yet Another Computer Algebra System, (NdT : encore un autre logiciel de calcul algébrique similaire à Mathematica).

À ce stade de mon parcours, les tests ne venaient qu’après coup. Mon méta-algorithme général était : bidouiller du code > voir si ça fonctionne> écrire (éventuellement) un test simple pour démontrer que ça fonctionne. Un test difficile à écrire n’était généralement jamais écrit.

C’est le premier pas sur la voie qui mène à la Lumière grâce aux tests. Vous savez que les tests sont probablement une bonne idée, mais vous n’en avez pas vu clairement les bénéfices, alors vous vous contentez de les écrire de temps en temps.

Si je pouvais ouvrir un trou de souris dans l’espace-temps et donner à mon moi plus jeune un conseil plein de sagesse sur les tests, ce serait :

« Certains tests sont plus importants, sur le long terme, que le code qu’ils testent. »

Il y a sans doute quelques personnes qui pensent en ce moment même que je mets mon casque de protection psychique (NdT : il s’agit d’un chapeau pour se protéger contre la manipulation à distance du cerveau) quand je m’assois pour écrire du code. Comment les tests pourraient-ils être plus importants que le code qu’ils testent ? Les tests sont la preuve que votre code marche réellement ; ils vous montrent le chemin vers l’écriture d’un code propre et vous apportent aussi la souplesse qui vous permettra de modifier le code tout en sachant que les fonctionnalités seront toujours là. En effet, plus votre code source grossit, plus vos tests sont importants, car ils vous permettent de changer une partie dudit code en sachant que le reste fonctionnera.

Une autre raison essentielle qui justifie l’écriture de tests est la possibilité de spécifier que quelque chose est un souhait explicite et non une conséquence imprévue ou un oubli. Si vous avez un cahier des charges, vous pouvez utiliser des tests pour vérifier qu’il est respecté, ce qui est très important, voire indispensable dans certaines industries. Un test, c’est comme quand on raconte une histoire : l’histoire de votre conception du code et de la façon dont il devrait fonctionner. Soit le code change et évolue, soit il mute en code infectieux (1).

Très souvent, vous écrirez des tests une première fois pour ensuite remettre totalement en cause votre réalisation voire la réécrire à partir de zéro. Les tests survivent souvent au code pour lesquels ils ont été conçus à l’origine. Par exemple, un jeu de tests peut être utilisé quel que soit le nombre de fois où votre code est transformé. Les tests sont en fait l’examen de passage qui vous permettra de jeter une ancienne réalisation et de dire « cette nouvelle version a une bien meilleure structure et passe notre jeu de tests ». J’ai vu cela se produire bien des fois dans les communautés Perl et Parrot, où vous pouvez souvent me voir traîner. Les tests vous permettent de changer les choses rapidement et de savoir si quelque chose est cassé. Ils sont comme des propulseurs pour les développeurs.

Les charpentiers ont un adage qui dit quelque chose comme ça :

« Mesurer deux fois, couper une fois. »

Le code serait la coupe, le test serait la mesure.

La méthode de développement basée sur les tests fait économiser beaucoup de temps, parce qu’au lieu de vous prendre la tête à bricoler le code sans but défini, les tests précisent votre objectif.

Les tests sont aussi un très bon retour d’expérience. Chaque fois que vous faites une nouvelle passe de test, vous savez que votre code s’améliore et qu’il a une fonctionnalité de plus ou un bogue de moins.

Il est facile de se dire « je veux ajouter 50 fonctionnalités » et de passer toute la journée à bricoler le code tout en jonglant en permanence entre différents travaux. La plupart du temps, peu de choses aboutiront. La méthode de développement basée sur les tests aide à se concentrer sur la réussite d’un seul test à la fois.

Si votre code échoue devant ne serait-ce qu’un seul test, vous avez pour mission de le faire réussir. Votre cerveau se concentre alors sur quelque chose de très spécifique, et dans la plupart des cas cela produit de meilleurs résultats que passer constamment d’une tâche à une autre.

La plupart des informations relatives au développement basé sur les tests sont très spécifiques à un langage ou à une situation, mais ce n’est pas une obligation. Voilà comment aborder l’ajout d’une nouvelle fonctionnalité ou la correction d’un bogue dans n’importe quel langage :

1. Écrivez un test qui fait échouer votre code, mais qui, selon vous, sera passé quand la fonctionnalité sera implémentée ou que le bogue sera corrigé. Mode expert : pendant l’écriture du test, pensez à l’exécuter de temps en temps, même s’il n’est pas encore fini, et tentez de deviner le message d’erreur effectif que le test renverra. À force d’écrire des tests et de les faire tourner, cela devient plus facile ;
2. Bidouillez le code ;
3. Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
4. C’est fini ! Dansez le sirtaki.

Cette méthode fonctionne pour n’importe quel type de test et n’importe quel langage. Si vous ne deviez retenir qu’une seule chose de ce texte, souvenez-vous des étapes ci-dessus.

Voici maintenant quelques directives plus générales de conduite de tests qui vous serviront bien et fonctionneront dans n’importe quelle situation :

1. Comprendre la différence entre ce qu’on teste et ce qu’on utilise comme un outil pour tester autre chose ;
2. Les tests sont fragiles. Vous pouvez toujours écrire un test qui contrôle la validité d’un message d’erreur. Mais que se passera-t-il si le message d’erreur change ? Que se passera-t-il quand quelqu’un traduira votre code en catalan ? Que se passera-t-il lorsque quelqu’un exécutera votre code sur un système d’exploitation dont vous n’avez jamais entendu parler ? Plus votre test est résistant, plus il aura de valeur.

Pensez à cela quand vous écrivez des tests. Vous voulez qu’ils soient résistants, c’est-à-dire que les tests, dans la plupart des cas, ne devraient avoir à changer que quand les fonctionnalités changent. Si vous devez modifier vos tests régulièrement, sans que les fonctionnalités aient changé, c’est que vous faites une erreur quelque part.

Types de tests

Bien des personnes sont perdues quand on leur parle de tests d’intégration, tests unitaires, tests d’acceptation et autres tests à toutes les sauces. Il ne faut pas trop se soucier de ces termes. Plus vous écrirez de tests, mieux vous en distinguerez les nuances et les différences entre les tests deviendront plus apparentes. Tout le monde n’a pas la même définition de ce que sont les tests, mais c’est utile d’avoir des termes pour décrire les types de tests.

Tests unitaires contre tests d’intégration

Les tests unitaires et les tests d’intégration couvrent un large spectre. Les tests unitaires testent de petits segments de code et les tests d’intégration vérifient comment ces segments se combinent. Il revient à l’auteur du test de décider ce que comprend une unité, mais c’est le plus souvent au niveau d’une fonction ou d’une méthode, même si certains langages appellent ces choses différemment.

Pour rendre cela un peu plus concret, nous établirons une analogie sommaire en utilisant des fonctions. Imaginez que f(x) et g(x) soient deux fonctions qui représentent deux unités de code. Pour l’aspect concret, supposons qu’elles représentent deux fonctions spécifiques du code de base de votre projet libre et open source.

Un test d’intégration affirme quelque chose comme la composition de la fonction, par exemple f(g(a)) = b. Un test d’intégration consiste à tester la façon dont plusieurs choses s’intègrent ou travaillent ensemble, plutôt que la façon dont chaque partie fonctionne individuellement. Si l’algèbre n’est pas votre truc, une autre façon de comprendre est de considérer que les tests unitaires ne testent qu’une partie de la machine à la fois, tandis que les tests d’intégration s’assurent que la plupart des parties fonctionnent à l’unisson. Un bel exemple de test d’intégration est le test de conduite d’une voiture. Vous ne vérifiez pas la pression atmosphérique, ni ne mesurez le voltage des bougies d’allumage. Vous vous assurez que le véhicule fonctionne globalement.

La plupart du temps, il est préférable d’avoir les deux. Je commence souvent avec les tests unitaires puis j’ajoute les tests d’intégration au besoin puisqu’on a besoin d’éliminer d’abord les bogues les plus basiques, puis de trouver les bogues plus subtils issus d’un emboitement imparfait des morceaux, à l’opposé de pièces qui ne fonctionnent pas individuellement. Beaucoup de gens écrivent d’abord des tests d’intégration puis se plongent dans les tests unitaires. Le plus important n’est pas de savoir lequel vous écrirez en premier, mais d’écrire les deux types de tests.

Vers la Lumière

La méthode de développement basée sur les tests est un chemin, pas un aboutissement. Sachez apprécier le voyage et assurez-vous de faire une pause pour respirer les fleurs si vous êtes égaré. 

(1) Équivalent approché du terme bitrot qui en argot de codeur désigne ce fait quasi-universel : si un bout de code ne change pas mais que tout repose sur lui, il « pourrit ». Il y a alors habituellement très peu de chances pour qu’il fonctionne tant qu’aucune modification ne sera apportée pour l’adapter à de nouveaux logiciels ou nouveaux matériels.

Comic strip réalisé avec le Face-O-Matic de Nina Paley et Margot Burns

Copyheart ? 2011 by Margo Burns and Nina Paley. Copying is an act of love. Please copy!

Vous finirez par savoir tout ce qu’ils ont oublié

Leslie Hawthorn

Gestionnaire de communautés internationalement reconnue, conférencière et auteur, Leslie Hawthorn a plus de 10 ans d’expérience dans la gestion de projets high tech, le marketing et les relations publiques. Elle a récemment rejoint AppFog⁽¹⁾ en tant que responsable de la communauté, où elle est chargée du recrutement de développeurs. Auparavant, elle a travaillé comme responsable de communication au laboratoire open source de l’Université de l’état de l’Oregon et comme responsable de programme au sein de l’équipe open source de Google, où elle a géré le Google Summer of Code⁽²⁾, créé le concours que l’on connaît maintenant sous le nom Google Code-in et lancé le blog de développement open source de la société.

« La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment mettre rapidement le logiciel en route, une vue d’ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. Or, c’est exactement tout ce que les auteurs de la documentation connaissent parfaitement. Si parfaitement, qu’il peut être difficile pour eux de voir les choses du point de vue du lecteur, et d’énumérer laborieusement les étapes qui (aux yeux des auteurs) semblent évidentes ou inutiles à mentionner. » Karl Fogel, Produire du logiciel libre⁽³⁾

Quand pour la première fois vous commencez à travailler sur un projet de logiciel libre et open source, la courbe d’apprentissage est raide et le chemin difficile. Vous risquez de vous retrouver abonné à des listes de diffusion ou dans des salons de discussion avec toutes sortes de gens renommés, comme le créateur de votre langage de programmation favori ou le responsable de votre logiciel préféré, et vous vous demanderez si vous serez un jour suffisamment qualifié pour contribuer efficacement. Ce dont vous n’aurez pas forcément conscience, c’est à quel point ces gens sages ont oublié le long chemin qui les a menés au succès.

Prenons une analogie simple : dans un projet open source, le processus d’apprentissage, comme utilisateur ou comme développeur, c’est un peu comme apprendre à faire du vélo. Pour les cyclistes expérimentés, « c’est aussi facile que de monter à vélo ». Vous avez probablement fait du vélo quelques fois et vous comprenez son architecture : une selle, des roues, des pédales et un guidon. Pourtant, vous montez en selle, concentré sur votre avancée et soudainement vous découvrez que ce n’est pas aussi simple que ce que vous pensiez : à quelle hauteur faut-il régler votre selle ? Quel équipement vous faut-il quand vous grimpez une colline ? Quand vous en descendez une ? D’ailleurs, avez-vous vraiment besoin de ce casque ? (un conseil : oui, absolument).

Lorsque vous vous mettez au vélo, vous ne savez même pas quelles questions poser et vous ne les trouverez que dans vos genoux endoloris, des points de côté et des courbatures dans le dos. Même dans ce cas, vos questions ne correspondront pas toujours aux réponses dont vous avez besoin ; quelqu’un pourrait s’aviser de vous dire d’abaisser la selle quand vous lui dites que vos genoux font mal, mais d’autres peuvent aussi bien supposer que tout ça est nouveau pour vous et que vous finirez bien par le découvrir par vous-même. Ils ont oublié qu’il faut se battre avec les changements de vitesse, se rendre compte qu’on n’a pas les bons éclairages ni les réflecteurs adéquats, comment tourner à gauche en levant la bonne main, parce qu’ils font du vélo depuis si longtemps que tous ces gestes sont pour eux comme une seconde nature.

Le scénario reste le même lorsque vous débutez dans le monde des logiciels libres et open source. Lorsque vous compilez un paquet pour la première fois, vous allez inévitablement arriver à un obscur message d’erreur ou un autre genre d’échec. Et lorsque vous demanderez de l’aide, une bonne âme vous dira sans doute : « c’est facile, il suffit de faire make -toto -titi -tata ». Sauf que pour vous, ce n’est pas facile. Il n’y aura probablement pas de documentation pour toto, titi ne fera pas ce qu’il est supposé faire et qu’est ce que ce truc tata avec ses huit homonymes sur Wikipédia ? Évidemment, vous ne voulez pas être un boulet, mais vous allez avoir besoin d’aide pour réussir vraiment à faire quelque chose.

Vous allez peut-être persister à reprendre les mêmes étapes, rencontrer les mêmes échecs, et la frustration ira grandissant. Peut-être que vous allez vous lever pour prendre un café en pensant que vous reviendrez sur le problème plus tard. Ce qu’aucun de nous dans le monde des logiciels libres et open source ne voudrait voir se produire, c’est précisément ce qui se passe pour beaucoup : boire cette tasse de café est infiniment meilleur que de se sentir ignorant et intimidé, et vous n’allez pas plus avant dans votre découverte du Libre.

Prenez conscience dès maintenant que vous finirez par connaître ces choses que les experts autour de vous ont oubliées ou qu’ils ne communiquent pas car ces étapes sont évidentes pour eux. Toute personne plus expérimentée que vous est passée par les mêmes affres que vous en ce moment pour apprendre à faire ce que vous vous efforcez de faire. Voici quelques conseils pour rendre votre parcours plus facile :

N’attendez pas trop longtemps avant de demander de l’aide. Personne ne veut être un boulet et personne n’aime avoir l’air perdu. Cela dit, si vous n’arrivez pas à résoudre votre problème après avoir essayé pendant 15 minutes, il est temps de demander de l’aide. Vérifiez dans la documentation sur le site web du projet que vous utilisez le bon canal IRC, le forum ou la liste de diffusion pour demander de l’aide. De nombreux projets ont des canaux d’aide en ligne spécialement pour les débutants, gardez donc un œil sur des mots tels que mentor, débutant et mise en route.

Parlez de votre processus (de réflexion). Il ne s’agit pas seulement de poser des questions, mais de savoir quelles sont les bonnes questions à poser. Au début, vous ne saurez pas forcément quelles sont ces bonnes questions. Donc quand vous demanderez de l’aide, détaillez ce que vous essayez de faire, les étapes par lesquelles vous êtes passé, et les problèmes que vous avez rencontrés. Signalez aux futurs mentors du canal IRC ou de la liste de diffusion que vous avez lu le manuel en incluant des liens vers la documentation que vous avez lue sur le sujet. Si vous n’avez trouvé aucune documentation, le signaler poliment peut aider.

Apprenez à connaître votre propre valeur. En tant que nouveau contributeur dans un projet, vous êtes un atout précieux. Non pas pour vos connaissances, mais pour votre ignorance. Lorsque vous commencez à travailler sur des logiciels libres et open source, rien n’est assez évident à vos yeux et tout mérite donc d’être expliqué. Prenez des notes à propos des problèmes que vous avez rencontrés, et de la façon dont ils ont été résolus. Puis utilisez ces notes pour mettre à jour la documentation du projet, travailler avec la communauté à des démos vidéo ou autres documents de formation pour les cas les plus épineux. Quand vous rencontrez un problème vraiment frustrant, comprenez que vous êtes en position idéale pour faire en sorte que le prochain qui tombera dessus ne rencontrera pas les mêmes difficultés.

1. http://www.appfog.com/ ^{^}
2. http://fr.wikipedia.org/wiki/Google_Summer_of_Code ^{^}
3. http://framabook.org/8-produire-du-logiciel-libre ^{^}

Vous finirez par savoir tout ce qu’ils ont oublié

Leslie Hawthorn

Gestionnaire de communautés internationalement reconnue, conférencière et auteur, Leslie Hawthorn a plus de 10 ans d’expérience dans la gestion de projets high tech, le marketing et les relations publiques. Elle a récemment rejoint AppFog⁽¹⁾ en tant que responsable de la communauté, où elle est chargée du recrutement de développeurs. Auparavant, elle a travaillé comme responsable de communication au laboratoire open source de l’Université de l’état de l’Oregon et comme responsable de programme au sein de l’équipe open source de Google, où elle a géré le Google Summer of Code⁽²⁾, créé le concours que l’on connaît maintenant sous le nom Google Code-in et lancé le blog de développement open source de la société.

« La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment mettre rapidement le logiciel en route, une vue d’ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. Or, c’est exactement tout ce que les auteurs de la documentation connaissent parfaitement. Si parfaitement, qu’il peut être difficile pour eux de voir les choses du point de vue du lecteur, et d’énumérer laborieusement les étapes qui (aux yeux des auteurs) semblent évidentes ou inutiles à mentionner. » Karl Fogel, Produire du logiciel libre⁽³⁾

Quand pour la première fois vous commencez à travailler sur un projet de logiciel libre et open source, la courbe d’apprentissage est raide et le chemin difficile. Vous risquez de vous retrouver abonné à des listes de diffusion ou dans des salons de discussion avec toutes sortes de gens renommés, comme le créateur de votre langage de programmation favori ou le responsable de votre logiciel préféré, et vous vous demanderez si vous serez un jour suffisamment qualifié pour contribuer efficacement. Ce dont vous n’aurez pas forcément conscience, c’est à quel point ces gens sages ont oublié le long chemin qui les a menés au succès.

Prenons une analogie simple : dans un projet open source, le processus d’apprentissage, comme utilisateur ou comme développeur, c’est un peu comme apprendre à faire du vélo. Pour les cyclistes expérimentés, « c’est aussi facile que de monter à vélo ». Vous avez probablement fait du vélo quelques fois et vous comprenez son architecture : une selle, des roues, des pédales et un guidon. Pourtant, vous montez en selle, concentré sur votre avancée et soudainement vous découvrez que ce n’est pas aussi simple que ce que vous pensiez : à quelle hauteur faut-il régler votre selle ? Quel équipement vous faut-il quand vous grimpez une colline ? Quand vous en descendez une ? D’ailleurs, avez-vous vraiment besoin de ce casque ? (un conseil : oui, absolument).

Lorsque vous vous mettez au vélo, vous ne savez même pas quelles questions poser et vous ne les trouverez que dans vos genoux endoloris, des points de côté et des courbatures dans le dos. Même dans ce cas, vos questions ne correspondront pas toujours aux réponses dont vous avez besoin ; quelqu’un pourrait s’aviser de vous dire d’abaisser la selle quand vous lui dites que vos genoux font mal, mais d’autres peuvent aussi bien supposer que tout ça est nouveau pour vous et que vous finirez bien par le découvrir par vous-même. Ils ont oublié qu’il faut se battre avec les changements de vitesse, se rendre compte qu’on n’a pas les bons éclairages ni les réflecteurs adéquats, comment tourner à gauche en levant la bonne main, parce qu’ils font du vélo depuis si longtemps que tous ces gestes sont pour eux comme une seconde nature.

Le scénario reste le même lorsque vous débutez dans le monde des logiciels libres et open source. Lorsque vous compilez un paquet pour la première fois, vous allez inévitablement arriver à un obscur message d’erreur ou un autre genre d’échec. Et lorsque vous demanderez de l’aide, une bonne âme vous dira sans doute : « c’est facile, il suffit de faire make -toto -titi -tata ». Sauf que pour vous, ce n’est pas facile. Il n’y aura probablement pas de documentation pour toto, titi ne fera pas ce qu’il est supposé faire et qu’est ce que ce truc tata avec ses huit homonymes sur Wikipédia ? Évidemment, vous ne voulez pas être un boulet, mais vous allez avoir besoin d’aide pour réussir vraiment à faire quelque chose.

Vous allez peut-être persister à reprendre les mêmes étapes, rencontrer les mêmes échecs, et la frustration ira grandissant. Peut-être que vous allez vous lever pour prendre un café en pensant que vous reviendrez sur le problème plus tard. Ce qu’aucun de nous dans le monde des logiciels libres et open source ne voudrait voir se produire, c’est précisément ce qui se passe pour beaucoup : boire cette tasse de café est infiniment meilleur que de se sentir ignorant et intimidé, et vous n’allez pas plus avant dans votre découverte du Libre.

Prenez conscience dès maintenant que vous finirez par connaître ces choses que les experts autour de vous ont oubliées ou qu’ils ne communiquent pas car ces étapes sont évidentes pour eux. Toute personne plus expérimentée que vous est passée par les mêmes affres que vous en ce moment pour apprendre à faire ce que vous vous efforcez de faire. Voici quelques conseils pour rendre votre parcours plus facile :

N’attendez pas trop longtemps avant de demander de l’aide. Personne ne veut être un boulet et personne n’aime avoir l’air perdu. Cela dit, si vous n’arrivez pas à résoudre votre problème après avoir essayé pendant 15 minutes, il est temps de demander de l’aide. Vérifiez dans la documentation sur le site web du projet que vous utilisez le bon canal IRC, le forum ou la liste de diffusion pour demander de l’aide. De nombreux projets ont des canaux d’aide en ligne spécialement pour les débutants, gardez donc un œil sur des mots tels que mentor, débutant et mise en route.

Parlez de votre processus (de réflexion). Il ne s’agit pas seulement de poser des questions, mais de savoir quelles sont les bonnes questions à poser. Au début, vous ne saurez pas forcément quelles sont ces bonnes questions. Donc quand vous demanderez de l’aide, détaillez ce que vous essayez de faire, les étapes par lesquelles vous êtes passé, et les problèmes que vous avez rencontrés. Signalez aux futurs mentors du canal IRC ou de la liste de diffusion que vous avez lu le manuel en incluant des liens vers la documentation que vous avez lue sur le sujet. Si vous n’avez trouvé aucune documentation, le signaler poliment peut aider.

Apprenez à connaître votre propre valeur. En tant que nouveau contributeur dans un projet, vous êtes un atout précieux. Non pas pour vos connaissances, mais pour votre ignorance. Lorsque vous commencez à travailler sur des logiciels libres et open source, rien n’est assez évident à vos yeux et tout mérite donc d’être expliqué. Prenez des notes à propos des problèmes que vous avez rencontrés, et de la façon dont ils ont été résolus. Puis utilisez ces notes pour mettre à jour la documentation du projet, travailler avec la communauté à des démos vidéo ou autres documents de formation pour les cas les plus épineux. Quand vous rencontrez un problème vraiment frustrant, comprenez que vous êtes en position idéale pour faire en sorte que le prochain qui tombera dessus ne rencontrera pas les mêmes difficultés.

1. http://www.appfog.com/ ^{^}
2. http://fr.wikipedia.org/wiki/Google_Summer_of_Code ^{^}
3. http://framabook.org/8-produire-du-logiciel-libre ^{^}

L’association Sésamath existe depuis 10 ans maintenant.

10 ans de projets au service des mathématiques dans l’éducation. 10 ans également, et par effet de bord, au service du logiciel libre, de par les choix des outils et des licences adoptées ainsi que la manière toute collaborative de travailler.

Avoir, entre autres, réussi à couvrir tout le collège avec des manuels scolaires libres qui représentent aujourd’hui près de 20% du marché, ça n’est pas rien ! (et c’est même du jamais vu au niveau mondial !)

L’occasion de faire le point avec Sébastien Hache, salarié et co-fondateur de l’association, qui nous annonce de bien bonnes et libres nouvelles.

En quelques mots, comment se porte Sésamath ?

Sébastien Hache : Sésamath se porte plutôt bien. L’envie et la passion sont toujours là, depuis maintenant plus de 10 ans. De nouveaux membres viennent régulièrement renforcer une équipe globalement stable et de plus en plus expérimentée. La grosse difficulté est de parvenir à maintenir les ressources existantes (de plus en plus utilisées : plus d’un million d’élèves inscrits à Labomep par exemple l’an dernier) tout en continuant à faire évoluer les outils et à élargir le champ : c’est un défi compliqué mais c’est aussi passionnant.

Que pensez-vous de la récente circulaire sur l’usage du logiciel libre dans l’administration ?

Nous pensons que c’est une très bonne chose et que cela constitue un bon élément d’appui pour tous ceux qui veulent promouvoir les ressources et logiciels libres dans l’enseignement.

Que pensez-vous de l’opération Open TextBook de l’État californien ?

Plus il y aura de ressources éducatives libres et ouvertes, et mieux ce sera !

Que pensez-vous de la récente introduction de l’option Informatique et Sciences du Numérique en Terminale S ? Pensez-vous vous y impliquer de près ou de loin ?

Sesamath a fait le choix de ne pas se positionner sur des sujets autres que ceux inscrits dans ses statuts. Les objectifs de Sesamath nous occupent déjà largement.

Alors, justement, Sésamath a annoncé des nouveaux projets au lycée et dans le primaire. Peux-tu nous en dire plus ?

Pour l’instant, l’essentiel des projets de Sésamath se concentrait sur le collège, même si depuis longtemps, en particulier au niveau des liaisons inter-cycles, des ressources collège étaient utilisées en CM2 ou en seconde. C’est donc assez naturellement que nous avons lancé des appels (toujours en vigueur pour ceux que ça intéresse) dans ces deux directions pour amorcer des projets éditoriaux. En effet, l’expérience de Sésamath au collège a montré que le travail collaboratif autour d’ouvrages destinés à être publiés sur papier (même s’ils ont nativement une version numérique) était un bon catalyseur pour créer ensuite d’autres ressources numériques : un peu comme si l’ouvrage éditorialisé servait de fil conducteur pour tout le reste. Paradoxalement, le papier est aussi une bonne façon de faire connaître le numérique.

En CM2, une équipe composée de professeurs des écoles et de professeurs de collège travaille actuellement à un cahier d’exercices sur le modèle des cahiers d’exercices de collège (afin d’avoir une continuité dans la ressource). Ce cahier est destiné à être sous licence libre (CC By-Sa) : pour l’instant, durant la phase de conception, seuls les enseignants inscrits à Sésaprof peuvent y avoir accès mais quand il sera achevé (début 2013) il sera intégralement téléchargeable pour tous aux formats ODT et PDF. En même temps, nous concevons le cahier numérique associé. Une autre équipe construit en parallèle le futur manuel Sésamath 6e, qui est très largement modifié par rapport au précédent en partie justement pour tenir compte de la liaison.

En seconde, une équipe composée de professeurs de collège et de lycée travaille sur un manuel complet. Ce manuel est écrit en LaTex. Il sera de la même façon publié sous licence libre et accompagné d’un manuel numérique gratuit. Le premier chapitre sera très prochainement mis en ligne. Beaucoup de lecteurs de ce blog seront heureux de voir que Sésamath produit collaborativement un ouvrage en Latex (c’était déjà le cas pour un ouvrage d’exercices en classes préparatoires) !

Pour résumer, nous travaillons cette année sur 3 ouvrages en même temps. C’est possible grâce à l’expérience de l’association et de ses membres sur la création collaborative de manuels scolaire (organisation, outils…), mais aussi les licences libres et les formats ouverts qui permettent ce mode de création et motive les auteurs.

En parlant de format ouvert, il se dit que Sésamath est en train d’abandonner Flash. Qu’en est-il ?

Effectivement, une grande partie des ressources interactives de Sésamath (dont l’exerciseur Mathenpoche) a été développé en Flash. Il y a déjà eu pas mal de discussions sur ce point : avec le recul, il n’y a sans doute rien à regretter, mais on se rend compte actuellement que cela nous mène à une impasse. Avant d’être technique, l’impasse est d’abord collaborative : nous n’avons pas réussi à former suffisamment d’enseignants à la programmation en Flash et nous nous sommes coupés d’une communauté de développeurs dont nous avons grand besoin aujourd’hui.

C’est pourquoi, Sésamath s’est donné les moyens, depuis plus d’un an maintenant, de créer un nouveau modèle d’activités intéractives : Il s’agit du projet J3P basé sur les technologies web modernes (html5/javascript). D’une certaine façon, Sésamath a terminé sa mue complète vers le libre (je me permets de remercier tous ceux qui ont contribué à ça, de façon souvent très intelligente et patiente, et parmi ceux-là évidemment toute l’équipe de Framasoft). Mais l’intérêt de J3P ne réside pas que dans son format : il ouvre aussi des pistes importantes du point de vue pédagogique. L’idée est de pouvoir créer des ressources de plus en plus adaptées aux difficultés de chaque élève en leur proposant des exercices où les réponses qu’ils donnent conditionnent les questions suivantes, pour tenter de s’adapter à la nature de leurs difficultés éventuelles.

Le projet J3P veut donc offrir aux enseignants un moyen de concevoir de tels exercices. L’enseignant pourra construire ou paramétrer le graphe de chaque exercice. Ce graphe décrit, suivant les réponses de l’élève à chaque étape, les différents parcours possibles parmi les sections qui composent l’exercice. Le projet J3P est sous licence GPL.

Toutes les bonnes volontés sont les bienvenues (ne pas hésiter à nous contacter.

Crédit illustration : Brochure Sésamath

Ah, les fameux App Stores et leurs effets pernicieux à plus d’un titre !

Ce système multiplie les coûts, les contraintes et les délais alors que la même application écrite dans le langage du Web et proposée directement aux visiteurs d’un site Web évite tous ces écueils.

En effet : non seulement le principe des App Stores autorise une entreprise privée à décider arbitrairement des seuls contenus auxquels les utilisateurs du monde entier auront le droit d’accéder, non seulement il permet d’enchaîner ces mêmes utilisateurs à un système d’exploitation donné (iOS, Android…)^[1], mais surtout, si l’on en croit David Murphy — qui commercialise un outil d’aide à la création d’applications Web — dans le texte ci-après traduit, il est tout à fait contre-productif pour les entreprises désirant proposer une application à l’appui de leur business.

Si les arguments techniques et économiques permettent aux applications Web de triompher des applications natives servies dans les App Stores fermés, ne nous privons pas de les relayer car, au final, tout cela permettra de rendre un peu de liberté à l’utilisateur !

Voici pourquoi HTML5 est génial pour les mobiles

Why HTML5 Rocks For Mobile

David Murphy – août 2012 – Mobile Marketing
(Traduction Framalang : antistress, Goofy, Amine Brikci-N, ZeHiro)

HTML5 est partout cette année ! Google encourage son usage. Facebook est à fond dessus. Il est évident que HTML5 est l’avenir sur les mobiles. OK c’est super. Mais c’est quoi au juste HTML5, et que peut-il faire pour les mobiles ?

HTML5 est la dernière version de HTML — le standard de présentation et de structuration des contenus sur le World Wide Web. Un des grands progrès apportés par HTML5 est qu’il permet à des sites web de fonctionner comme des applications mobiles, en donnant aux développeurs des moyens de conception adaptés aux appareils mobiles et plus seulement aux ordinateurs de bureau ou portables. Cela signifie que les sites web peuvent être conçus pour s’adapter aux écrans des appareils mobiles et avoir une interface utilisateur facile à maîtriser et très fonctionnelle avec les écrans tactiles. Le terme utilisé pour cette technologie est « appli web » (web app).

Sur un plan pratique, il existe deux façons d’implémenter une appli web. La première consiste à concevoir des sites web pour qu’ils s’adaptent et s’affichent aussi bien sur un écran d’ordinateur que sur un écran de smartphone. La seconde revient à créer une appli spécifique qui s’ouvrira lorsqu’on accède au site web avec un appareil mobile.

Cette nouvelle approche dans la présentation des contenus pour mobiles abat certaines barrières — y compris celles du temps, de l’argent et de l’omniprésent App Store. Les portes sont maintenant largement ouvertes pour les individus et les petites entreprises. Les poids lourds de la profession sont aussi attirés par cette alternative, à mesure qu’ils prennent conscience de ses avantages.

Qui n’a pas son smartphone

Voici des données chiffrées sur le marché des mobiles : 50% de toutes les recherches locales sont effectuées aujourd’hui sur des appareils mobiles. Ceci est largement dû au fait que les possesseurs de smartphones sont plus nombreux que ceux qui ont des téléphones basiques aux États-Unis et dans d’autres pays.

Et malgré cela, la plupart des entreprises n’ont aucune solution à proposer pour le mobile — sans compter les bénéfices substantiels qu’ils pourraient en tirer. Malheureusement, le développement d’applications classiques est tout simplement bien trop coûteux en temps et en argent et trop technique. Alors sans plus tarder, voyons cinq bonnes raisons qui nous font penser que HTML5 va poursuivre sa forte croissance :

Ça n’est pas seulement pour les iPhones, mais pour TOUS les smartphones

Malgré tout le buzz que génère l’iPhone, il ne représente que 25% des parts de marché. Android domine le marché avec 50% des smartphones en Amérique du Nord et Blackberry s’en sort étonnamment bien du côté des tablettes. Les appli web fonctionnent sur tous les téléphones et tablettes tactiles populaires — vous permettant d’atteindre la quasi-totalité des clients. Ce n’est pas qu’une chose positive, c’est surtout crucial pour les affaires.

C’est abordable

Les applis web HTML5 sont développées pour un prix et un temps moitié moindres que les applications natives (basées sur du code machine). Développer des applications natives peut aussi être un cauchemar. Je répète : un cauchemar coûteux en temps et en argent. Développer pour une plateforme spécifique (iPhone, Android, Blackberry, Windows Mobile, iPad et la liste est encore longue…) n’est tout simplement pas une solution viable pour la plupart des entreprise, et ceci empire car…

Les choses changent. Votre entreprise changera.

Imaginez que vous possédez une entreprise et que votre nouvelle application native a été lancée il y a six mois de cela ; votre entreprise et vos clients ont changé ne serait-ce qu’un petit peu et vous devez faire une mise à jour. Bonne chance ! Commencez par trouver l’équipe de développeurs, impliquez à nouveau vos équipes marketing et vente, et apprêtez-vous à tous les payer encore une fois. Ensuite re-soumettez l’application à (aux) app store(s) concernés… et attendez.

Les applis web permettent une mise à jour rapide, au rythme de votre entreprise. Comme pour un site web, les modifications peuvent être mises en œuvre instantanément. Aucune autre solution pour mobile ne peut rivaliser lorsqu’il s’agit de permettre à une entreprise d’être réactive aux priorités et aux besoins en temps réel.

Localisation, localisation, localisation

La proximité est l’un des meilleurs moyens de susciter l’intérêt, d’être pertinent et finalement de déclencher l’acte d’achat. Les applis web ont la possibilité de fournir des services géolocalisés, comme d’informer les utilisateurs de la proximité de lieux pouvant les intéresser ou de leur permettre d’associer des contenus (par exemple des photos ou des notes) à des lieux particuliers.

Votre marque est sur le Web et sociale, pourquoi pas votre appli aussi ?

Qu’est-ce qu’un site web en fait ? C’est l’endroit où votre entreprise/marque/personne existe en ligne. Sauf que ce n’est plus uniquement cela avec le Web moderne. Les marques, les gens, les produits existent à travers l’ensemble du web – sur Twitter, Facebook, Yelp, Tumblr et des centaines (si ce n’est des milliers) d’autres services. Aujourd’hui c’est là que les connexions se font, que l’on trouve les produits et les gens, que les nouvelles idées grandissent.

Les applis web sont faites pour fonctionner et vivre avec les autres éléments de votre marque sur le Web — ce qui vous permet de rester en contact avec vos clients actuels, d’en trouver de nouveaux, ou simplement de partager des idées de toutes les manières possibles. Les applis web excellent, et pour cause, à fonctionner avec d’autres applications du Web.

Et ce n’est que le début, les gars ; attendez de voir la suite !

Crédit photo : Toni Hermoso Pulido (Creative Commons By-Sa)

Source : HTML5 : deux versions pour diviser les développeurs (Numerama)

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