Plus que jamais d’actualité suite à l’annonce par WikiLeaks du début de la publication de 250 000 câbles diplomatiques américains, voici une (relativement) nouvelle chanson de Dan Bull, sous-titrée comme pour les précédents morceaux par la fine équipe : Koolfy plus Framalang.
Dan Bull – WikiLeaks and the Need for Free Speech
—> La vidéo au format webm
—> Le fichier de sous-titres
Comme nous l’apprenait Lea-Linux le mois dernier :
GNU/Linux progresse sur les environnements dits critiques. On savait qu’il était utilisé sur les serveurs sensibles des militaires, des grands organismes de recherche, de la NASA et de nombreux industriels, ajoutons désormais le monde de la finance à cette liste. En effet, Computer World UK nous apprend que la Bourse de Londres mettra en production le 15 novembre prochain sa nouvelle plate-forme à base de GNU/Linux et Solaris, pour remplacer la plate-forme boguée « TradElect » basée sur Microsoft Windows, et la technologie .Net manifestement trop lente.
GNU/Linux a notamment été choisi par les britanniques pour ses performances (des temps de transmission de 0,125 milliseconde ont été enregistrés lors des tests). Le fait que le Chicago Mercantile Exchange, la Bourse de Tokyo et le NYSE Euronext soient déjà passés à GNU/Linux (Red Hat) n’y est sans doute pas pour rien non plus.
[1]
London Stock Exchange completes first live Linux test
Leo King – 13 octobre 2010 – Computerworld UK
Traduction Framalang : Pablo, Barbidule, Siltaar, Kootox, Goofy, Petrus6, Martin, Don Rico, Daria
La Bourse de Londres a fait le premier test grandeur nature, avec des clients en ligne, d’un nouveau système fondé sur Linux et destiné à remplacer l’architecture actuelle basée sur des produits Microsoft et qui permettra d’échanger à la vitesse de 0.125 millisecondes.
Le système « Millennium Exchange » fonctionnant sur Linux et sur Unix (Sun Solaris) et utilisant les bases de données d’Oracle, remplacera le 1er novembre la plateforme TradElect, reposant sur Microsoft .Net, pour la plus grande bourse au monde. Il promet d’être le système d’échanges le plus rapide du monde, avec un temps de transaction de 0.125 milliseconde. La Bourse a terminé la migration de son système de gestion des transactions stagnantes/dormantes, ou anonymes, Turquoise, depuis différents systèmes, plus tôt ce mois-ci.
La BDL (Bourse De Londres) a refusé de dévoiler le verdict du test en avant-première du « Millenium Exchange », qui s’est déroulé samedi après plusieurs mois de tests hors ligne intensifs. Cependant, des sources proches de la Bourse ont indiqué qu’il se serait déroulé avec succès.
Une autre répétition générale aura lieu le 23 octobre, un peu plus d’une semaine avant le lancement dans le grand bain. La Bourse pousse pour lancer le service le 1er novembre, mais si les clients, les traders, ne sont pas prêts ou si des problèmes techniques apparaissent, une date de lancement alternative a été prévue au 15 novembre.
En attendant, la Bourse va continuer à travailler avec le système TradElect, basé sur une architecture Microsoft .Net et mis à jour par Accenture en 2008 pour 40 millions de livres (46 millions d’Euros). En juillet, elle a réservé 25,3 millions de livres (29,2 millions d’Euros) en coûts d’amortissement sur TradElect.
TradElect, sujet de nombreuses controverses ces dernières années, avait subi une série de pannes de grande envergure, la pire étant un arrêt de huit heures en 2008. À l’époque, la BDL avait maintenu que TradElect n’était pas responsable de la panne, mais a néanmoins, tenté de remplacer la plateforme depuis, en faisant l’acquisition de la société MilleniumIT, le fournisseur de ce nouveau système.
Les vitesses réseau sont aussi une des raisons principales de ce changement. La BDL a tenté désespérément de descendre les temps de transaction sur TradElect en-dessous des 2 millisecondes, une vitesse léthargique comparée à la concurrence comme Chi-X qui annonce des temps de moins de 0,4 millisecondes.
La BDL annonce que sa nouvelle plateforme d’échange aura des temps de réponse de 0,125 millisecondes, ce qui pourrait en faire une des plateformes d’échange les plus rapides du monde. Le changement est particulièrement important étant donné la progression des transactions algorithmiques, où des ordinateurs placent automatiquement des millions d’ordres d’achat et de vente alors que les prix des actions changent.
Lors d’une interview cette semaine dans le Financial Times, le directeur général de la Bourse de Londres, Xavier Rolet a déclaré que la Bourse avait « déjà prévu » la prochaine génération d’améliorations technologiques pour maintenir la plateforme Millenium à la pointe de la technologie en terme de vitesse de transaction.
Se connecter à un Wifi public dans un parc, une gare ou un café [1] pour accéder à Internet, c’est un peu comme passer par la salle d’attente du médecin avant une consultation. Dans les deux cas, vous avez confiance en votre destination [2], mais vous êtes au préalable enfermé dans un espace avec des étrangers, tous plus ou moins malades.
En effet, le WiFi d’un café vous connecte, comme la salle d’attente, avec votre entourage direct, sans que vous ayez rien demandé. Or, si votre dossier médical est confidentiel, il suffit de faire tomber ses papiers dans une salle d’attente pour que toutes les personnes présentes puissent les lire, et il suffit de se connecter (via un WiFi public) à un service qui n’utilise pas le protocole HTTPS pour que votre entourage connecté puisse s’immiscer dans votre session et votre intimité.
Les coupables ? Les sites conservant à votre place des éléments de votre vie privée d’une part, et proposant d’autre part et sans la protection du petit cadenas qui dénote de l’utilisation du protocole HTTPS, de « garder votre session ouverte » grâce à un cookie. Si vous y prenez garde, ce n’est pas le cas des services en ligne de votre banque.
Toutefois, si l’auteur est assez pessimiste dans son petit billet complémentaire (reproduit ici à la suite du premier) face aux moyens de protection à notre disposition, il existe plusieurs extensions Firefox pour limiter les risques sans trop se compliquer la vie, citons (sur les bons conseils de Goofy) HTTPS Everywhere, et Force-TSL. De plus, il me semble également assez simple de se connecter, où qu’on soit, d’abord à un VPN personnel, ou directement en SSH sur son serveur à soit (voir l’extension Foxyproxy de Firefox), pour surfer ensuite l’esprit tranquille et sans laisser de traces locales, comme si on était à la maison. D’ailleurs, votre WiFi chez vous, il est protégé comment ?
Herding Firesheep in New York City
Gary LosHuertos – 27 octobre 2010 – TechnologySufficientlyAdvanced.blogspot.com
Traduction Framalang : Goofy, Pablo, cheval_boiteux
On a beaucoup parlé de Firesheep ces derniers jours. Cette extension gratuite pour Firefox récolte pour vous les cookies qui sont envoyés depuis un réseau WiFi non protégé n’utilisant pas le protocole SSL. Vous la mettez en route, elle collecte les cookies de Facebook, Twitter et de 24 autres sites (par défaut). Ensuite, vous pouvez voler l’identité d’un compte et obtenir l’accès sous cette identité.
L’extension n’a rien de scandaleux en elle-même. Si vous êtes un développeur un peu compétent, vous savez depuis longtemps que cette faille existait, n’est-ce pas ? Mais quid du reste du monde ? Tous ces gens qui n’ont jamais entendu parler de cette nouvelle menace si facile d’accès, qui n’ont pas été alertés par leurs amis, qui ne regardent pas Engadget, ni Slashdot, ni ABC Pronews7 à Amarillo ?
Je me suis dit que j’allais faire passer le message et aider les béotiens après leur travail, puisqu’il y a un grand Starbucks tout près de chez moi. J’y suis allé, j’ai acheté un peu de nourriture malsaine, j’ai ouvert mon portable et lancé Firesheep. Moins d’une minute plus tard, j’avais cinq ou six identités disponibles dans le panneau latéral. Trois d’entre elles étaient sur Facebook.
Absolument rien de surprenant ; Firesheep n’est pas magique, et tous ceux qui vont au Starbucks savent qu’un tas de gens y mettent à jour leur statut Facebook sans faire attention, tout en sirotant leur café au lait. J’ai pensé que j’allais y passer un peu plus de temps, j’ai donc écouté un peu de musique, parlé à quelques amis, et le plus important (mais pas le plus simple) je n’ai navigué sur aucun site avec le protocole standard HTTP (et surtout pas sur Facebook évidemment).
Environ une demi-heure plus tard, j’avais récolté entre 20 et 40 identités. Puisque Facebook était de loin le service le plus représenté (et qu’il détient plus d’informations personnelles que Twitter) j’ai décidé d’envoyer aux utilisateurs des messages depuis leur propre compte, pour les avertir des risques auxquels ils s’exposaient. J’ai fait un modèle de message sympa qui précisait la localisation du Starbucks, la nature de la vulnérabilité, et comment y remédier. J’ai envoyé des messages aux 20 personnes autour de moi.
J’ai nettoyé le panneau latéral, retiré mes écouteurs, et j’ai attendu. J’ai entendu quelqu’un marmonner un juron pas très loin, et me suis demandé si mon message en était la cause. Pendant le quart d’heure suivant, je n’ai entendu strictement personne parler de ce qui venait se passer (pourtant ceux qui fréquentent les Starbucks ne sont le plus souvent pas du genre à tenir des conversations discrètes). Pourtant, j’ai pu vraiment constater une nette chute du nombre d’identités que je pouvais récolter quand j’ai relancé Firesheep.
C’était un soulagement — en voilà qui avaient compris le message. Avec un peu de chance, ils allaient alerter leurs amis, mettre à l’abri leur femme et leurs enfants. J’ai de nouveau nettoyé le panneau latéral, et après une vingtaine de minutes de conversations impromptues j’ai vu que cinq identités que j’avais déjà croisées étaient revenues dans mon troupeau.
C’était assez surprenant. Avaient-ils reçu le premier message ? Je me suis mis sur leur compte avec leurs identifiants, et en effet ils l’avaient reçu. L’un d’entre eux était même sur Amazon.com, site contre lequel j’avais mis en garde dans mon premier message. Je l’ai choisi pour première cible : j’ai ouvert sa page perso sur Amazon, j’ai repéré un truc sur lequel il avait récemment jeté un coup d’œil et lui ai envoyé un mot : « non, c’est pas sérieux » sur Facebook depuis son propre compte, avec un clin d’œil sur ses goûts musicaux.
J’ai encore une fois effacé les identités, attendu dix minutes, et lorsque j’ai à nouveau rassemblé mon troupeau avec Firesheep, il était parti. Mais il y en avait encore quatre qui restaient là. Peut-être, me suis-je dit, qu’ils ont cru que c’était un message d’avertissement automatique les ciblant au hasard (bien que j’aie mentionné leur localisation dans un rayon d’une trentaine de mètres). Donc, un dernier message était nécessaire.
J’ai bricolé un très court message (le premier était peut-être trop long ?) et je l’ai envoyé aux quatre, une fois encore avec leur propre compte :
« C’était vraiment pas une blague l’avertissement sur la sécurité. Je n’enverrai plus d’autre message après celui-ci –– à vous de prendre sérieusement en main votre propre sécurité. Vous êtes au Starbucks XYZ connecté de façon non sécurisée, et absolument n’importe qui peut accéder à votre compte avec l’outil approprié nécessaire (et disponible à tous). »
Vingt minutes ont passé, et tous les quatre utilisaient encore Facebook frénétiquement. Encore une fois, j’ai envisagé qu’ils auraient pu ne pas recevoir le message, mais en vérifiant leur compte j’ai vu qu’ils l’avaient bel et bien reçu.
Voilà ce qu’il y a de plus choquant à propos de la sécurité sur Internet : ce n’est pas que nous soyons tous scotchés sur un réseau global qui tient avec des bouts de sparadrap et laisse béants d’horribles failles de sécurité ; ce n’est pas non plus qu’un outil librement disponible puisse récolter des cookies d’authentification ; et ce n’est toujours pas qu’il y ait des gens pas du tout au courant de l’un ni de l’autre. Ce qui est absolument incompréhensible, c’est qu’après avoir été averti d’un danger (et sur son propre compte !) on puisse tranquillement ignorer l’avertissement, et reprendre le fil de ses activités.
Mais enfin j’ai tenu parole et n’ai pas envoyé d’autre message. J’ai rangé mon matériel, fait un petit tour dans le café, et reconnu plusieurs personnes auxquelles j’avais montré leur vulnérabilité. Je n’avais pas laissé d’indices sur ma propre identité, moins par crainte de rétorsion que parce que l’intrusion dans la vie privée est encore plus traumatisante quand elle est commise par un étranger complet, dont on n’a pas la moindre chance de découvrir l’identité.
En revenant chez moi, j’ai réfléchi à ce que cette expérience révélait de notre société. Peu importe le nombre de mesures de sécurité que nous procurons au monde entier, il y aura toujours des gens qui laisseront la porte ouverte, même s’ils ont été victimes d’une intrusion. Le maillon le plus faible de la sécurité c’est et ce sera toujours la décision de l’utilisateur.
De retour dans mon appartement, j’ai commencé à m’installer — et c’est le moment où je me suis rendu compte que pendant toute la soirée j’avais eu la braguette grande ouverte. La preuve par neuf finalement : nous nous baladons tous avec des vulnérabilités qu’il nous reste à découvrir.
Gary LosHuertos – 04 novembre 2010 – TechnologySufficientlyAdvanced.blogspot.com
Traduction Framalang : Siltaar, RaphaelH, Goofy
À la suite du billet précédent, je me suis dit qu’en voulant faire court j’avais omis quelques informations. Ceci sert donc d’addendum à mon précédent billet, et a été rédigé de la manière la plus courte possible.
Le message original envoyés aux clients était le suivant :
Comme vous utilisez Facebook sans chiffrement dans un Starbucks, votre compte a été compromis. Je ne suis qu’un amical client du Starbucks qui a souhaité vous prévenir de cette vulnérabilité.
Vous pouvez en apprendre davantage en cherchant des informations sur « Firesheep ». Il n’y a pas vraiment de solutions disponibles pour protéger votre compte Facebook lorsque vous êtes connectés à un réseau public, et je vous recommande donc simplement de ne pas vous y connecter lorsque vous êtes dans un Starbucks. Cette faille affecte également Twitter, Amazon.com, Google (mais pas Gmail), et quantité d’autres services.
Votre mot de passe n’a pas été compromis. Vous déconnecter de Facebook est tout ce que vous avez besoin de faire.
Pour préciser mes motivations, laisser un compte Facebook sans protection ne signifie pas seulement que quelqu’un peut regarder vos photos, vos coups de cœurs et messages. Un compte Facebook compromis donne à quelqu’un d’autre l’accès à votre identité, lui permettant de se faire passer pour vous auprès de vos amis, ruinant potentiellement des relations. S’il est possible de rattraper les choses ensuite, le temps et l’énergie que ça demande sont importants, surtout pour quelqu’un qui a beaucoup d’amis. Quelqu’un envoyant un faux message à l’un de vos amis n’est peut être pas un gros problème, mais un faux message envoyé à 500 de vos amis est déjà plus gênant. D’autant plus qu’il peut y avoir des collègues de travail, des membres de votre famille, ou des clients dans ces 500 personnes.
Concernant la légalité de mes actions : ça n’était pas l’objet de mon article. On peut toujours spéculer sur fait que je finisse en prison, mais c’est hors sujet par rapport à ce dont je parle dans mon billet : les sites non protégés comme Facebook et Twitter sont dangereux pour leurs utilisateurs. Il semble plus intéressant de consacrer son énergie à faire passer le mot plutôt que de troller sur mon éventuelle incarcération.
Enfin concernant ce que les utilisateurs peuvent faire, la meilleure réponse à l’heure actuelle est : rien. Ne vous connectez pas aux réseaux non protégés pour utiliser ces sites web, ou bien utilisez une application qui n’utilise pas d’authentification par cookie non protégée (pour ce que j’en sais, l’application Facebook pour iPhone ne le ferait pas). Assurez-vous que votre réseau WiFi domestique est chiffré en WPA, voire en WPA2 (le WEP est trivialement déchiffrable). Si vous utilisez Facebook au travail sur une connection sans-fil, vérifiez le chiffrement du réseau. La faille de sécurité ne vient pas seulement de Firesheep, elle vient du manque de protection des connexions. La menace la plus grande vient des outils automatisés qui existent depuis des années [3].
Sur le Framablog, on ne manque pas une occasion d’agir contre la censure, ou de publier le témoignage d’un citoyen s’élevant contre les menaces et restrictions faites à nos libertés fondamentales [1]. Parce qu’après tout, et comme me le fit un soir remarquer Benjamin Bayart, qu’est-ce qui nous motive tous dans le mouvement du Logiciel Libre ? Et dans la défense de la neutralité du réseau qui lui est indispensable ? Qu’est-ce qui nous réunit, si ce n’est la liberté d’expression ? Cette petite flamme fragile et dangereuse qui vacille au souffle du pouvoir et nécessite, pour être entretenue, notre attention constante.
Le témoignage que nous vous proposons aujourd’hui est celui de Theocrite, un « administrateur système » engagé pour le Logiciel Libre, qui nous explique comment TF1 [2] a silencieusement fait censurer par Google un extrait vidéo de débat à l’Assemblée Nationale.
On savait déjà que certains n’hésitent pas à attaquer, en vertu du Copyright de sa bande son, une vidéo compromettante, au mépris du « fair-use » largement accordé aux vidéos de lolcats. Mais cet extrait, posté par La Quadrature du Net, n’a lui pour seule bande son que le discours à l’Assemblée des députés de la République. Cela n’a pourtant pas arrêté TF1 [3] dans son coup de poker, son nouveau coup de poignard dans le dos de l’éthique et de notre liberté d’information.
Cette vidéo, c’est celle du rejet intégral par l’Assemblée Nationale du projet de loi HADOPI 1 le 9 avril 2009, et, pour illustrer le principe selon lequel une tentative de censure s’avère toujours contre-productive pour le censeur, la voici, archivée dans notre collection Framatube :
—> La vidéo au format webm
Theocrite – 1er novembre 2010
En me promenant sur le compte YouTube de la Quadrature du Net, j’ai découvert récemment dans les paramètres du compte que certaines vidéos étaient listées comme pouvant « comporter un contenu appartenant à un tiers ».
Hm, c’est possible… Intrigué, je clique sur le lien proposé et je m’aperçois que la vidéo en question est la vidéo du rejet de la loi HADOPI l’Assemblée Nationale.
Bigre ! Voilà que des vidéos contenant des discours « prononcés dans les assemblées politiques » serait en contradiction avec le droit d’auteur. Voilà qui est bien étrange.
Pour en savoir plus, je clique sur « Afficher les informations sur les droits d’auteur ».
On y apprend des choses très intéressantes… Comme le fait que les vidéos produites dans l’hémicycle seraient la propriété de « lgl_tf1 ». Un peu présomptueux de la part de la vieille chaîne qui descend.
Bon, portons réclamation. Après avoir lu une page chiante à mourir, on accède à un formulaire de réclamation, fortement limité, mais je suis décidé à faire avec.
Je fais alors subtilement remarquer que dans la législation française, les débats politiques sont publics… Puis je valide l’envoi du formulaire.
Le lendemain, je constate que j’ai obtenu gain de cause : la vidéo est débloquée. Mais pour combien de temps ? Google n’a pas pris la peine de nous notifier que la vidéo était à nouveau disponible. On pouvait toujours attendre en relevant notre boîte mail.
Google est réactif, mais pas spécialement poli. Pas de notifications lors du blocage de la vidéo, ni lors du déblocage.
La vidéo a été bloquée pendant un certain temps. Combien de temps ? Aucune idée. Mais TF1 a tenté et a réussi à faire censurer la vidéo, peu importe combien de temps, et ce sans rien risquer. C’est un jeu permanent dans lequel les plaignants ne peuvent pas perdre et les internautes ne peuvent pas gagner.
Ce n’est pas une nouvelle, pour TF1 quand il s’agit d’HADOPI, tous les moyens sont bons pour supporter la loi. Que ce soit en inventant un plébiscite lors d’un vote, en censurant son rejet comme nous venons de le voir ou encore en s’occupant des « salariés qui, manifestement, aiment tirer contre leur camp. »
Mais sur YouTube, TF1 ne s’arrête pas à HADOPI. TF1 sort le bulldozer. Je vous invite à rechercher lgl_tf1 dans un moteur de recherche. Celui de nos amis possesseurs de YouTube par exemple, ou bien sur un moteur de recherche libre, vous y trouverez des réactions unanimes d’Internautes énervés, soit parce que lgl_tf1 a bloqué des vidéos de France 2. Soit parce que TF1 a bloqué des vidéos sur lesquelles elle a acquis les droits de diffusions pour une certaine partie du monde, et se passe de demander aux auteurs s’ils autorisent cette rediffusion.
[1] Telles que garanties par la déclaration des droits de l’Homme et du citoyen, et rappelées par le « considérant n°12 » de la décision n°2009-580 DC du 10 juin 2009 du Conseil Constitutionnel concernant HADOPI 1 par exemple.
[2] Crédit première illustration : Vidberg © LeMonde.fr, reproduite avec l’aimable autorisation de l’auteur. Licence équivalente à une CC-By-NC-ND avec autorisation préalable requise.
[3] Ou peut-être un imposteur, que le chaîne laisserait agir « en son nom » depuis plus de deux ans.
Après LL de Mars, Gee et Harrypopof, Odysseus a tenu lui aussi à illustrer, avec humour, la campagne “1000 10 1” qui décidera du sort de l’association.
Et pour se dérider un peu en ces temps de crise, il a imaginé une nouvelle version de la comédie musicale Starmania, pourtant encore terriblement d’actualité 32 ans après sa sortie… Un peu plus geek que l’originale, la nouvelle version d’Odysseus a l’avantage de témoigner de 30 années de développement de l’informatique et du logiciel libre ! [1] [2]
D’ailleurs, je vous invite à poster vos propres titres en commentaire !
[1] Crédit : Odysseus – Licence Art Libre
[2] PS d’Odysseus : Notez que l’image de Richard Stallman a été proposée sur Openclipart par casifish
Framatube, comme les lecteurs assidus de ce blog le savent déjà, est une initiative lancée il y a environ deux ans, dans le but de regrouper des vidéos en rapport avec le logiciel libre et sa culture, pour en favoriser la diffusion.
Framatube s’appuie pour cela aujourd’hui sur la plateforme Blip.tv et, pas de mystère, sur le travail de bénévoles chargés de produire des sous-titres lorsque la vidéo est dans une langue étrangère, l’équipe Framalang entrant alors dans la danse [1].
Dans ce dernier cas, le travail nécessaire pour proposer la vidéo sous-titrée va au delà de la simple traduction : il faut préalablement transcrire la bande-son pour la traduire, puis synchroniser les sous-titres obtenus avec la bande-son, incruster les sous-titres et finalement encoder le tout dans un format libre. Cela demande un travail important, qui nécessite une motivation de longue haleine et plus de travail que les habituelles 6 ou 7 heures par traduction d’article publiée sur le Framablog.
D’autant que, les sous-titres étant au final incrustés dans la vidéo, tout ce travail ne peut être réutilisé pour proposer de nouvelles traductions dans d’autres langues.
Pour prendre l’analogie du logiciel, le code source qui pourrait permettre d’améliorer ou de modifier facilement le résultat n’est pas fourni : paradoxal pour un projet Framasoft !
Heureusement, la Participation Culture Foundation (fondation à but non lucratif à laquelle on doit notamment le logiciel de télévision par Internet Miro) développe « Universal Subtitles » un outil en-ligne qui simplifie grandement la tâche.
Ce projet se place sous le parrainage de la Mozilla Foundation, autre fondation à but non lucratif à qui l’on doit le fameux navigateur web Firefox et qui a initié le projet Mozilla Drumbeat pour promouvoir des initiatives comme celle-ci, visant à garder le Web Ouvert.
L’objectif d’Universal Subtitles est pour le moins ambitieux, offrir à chaque vidéo disponible sur le web un support de sous-titrage collaboratif, où chacun puisse participer au sous-titrage dans sa langue d’une vidéo rencontrée sur le web.
La solution retenue est habile puisqu’elle consiste, à partir d’une vidéo préexistante sur le Web :
Les avantages sont nombreux :
Et puis, cela promet de belles batailles concernant les sous-titres communautaires de clips musicaux…
Yostral, l’un des piliers de Framalang, a testé le système et publié un journal sur LinuxFr.org que nous reproduisons ici avec son aimable autorisation :
Je viens de tester le site UniversalSubtitles.org, qui se veut le « Wikipédia des sous-titres ».
Le but est simple : faciliter le sous-titrage dans n’importe-quelle langue de n’importe-quelle vidéo se trouvant sur le web.
Voyant les problèmes que nous avons à Framalang pour être efficace en sous-titrage vidéo, chacun faisant une étape dans son coin, sauf la traduction qui se fait sur wiki, pas adapté à ça, j’ai donc fait un petit test sur une simple vidéo, en français, pour voir les possibilité de travail collaboratif de traduction et de sous-titrage.
La première étape consiste bien sûr à « importer » une vidéo. En fait on travaille directement sur une vidéo déjà en ligne. Donc pas d’upload sur le site, pas de transcodage, rien. Il suffit simplement de donner l’adresse de la vidéo souhaitée. Pour le moment, les format supportés sont Ogg, WebM, FLV et donc les sites Youtube et Blip.TV (Dailymotion et Vimeo sont en cours).
Cette vidéo apparaît ensuite dans leur « Widget » de traduction. Une page je suppose remplie de HTML5 et de javascript, qui offre une interface relativement conviviale, claire et avec des raccourcis clavier. C’est succinct, mais suffisant pour faire ce qu’on lui demande. C’est donc ici que se déroule la première des trois étapes qui mènent au sous-titrage original de la vidéo : taper les sous-titres correspondant à la vidéo. Pour ceux qui ont 42 doigts, pas de soucis, vous laissez filer la vidéo et vous entrez le texte en temps réel… pour les autres, on peut toujours faire des pauses et naviguer avant/arrière tout simplement.
La seconde étape est la synchronisation du texte que vous avez tapé précédemment. Là, la vidéo défile et on doit appuyer sur une touche à chaque fois que l’on veut que le sous-titrage passe à la ligne suivante. Ici, faut être concentré ! Bien sûr, on peut mettre en pause, revenir en arrière, mais le mieux est de faire défiler et synchroniser au fur et à mesure. Faisable, mais pas évident, surtout sur la longueur.
La troisième étape est le peaufinage, où on peut ajuster les sous-titres plus précisément. Si on s’est un peu endormi à l’étape précédente, c’est ici qu’on se réveille.
Au final on nous donne un lien permanent vers la vidéo et ses sous-titres, ainsi qu’un bout de code pour l’intégration dans une page web. La vidéo est toujours la même au même endroit et seuls les sous-titres, qu’on peut se télécharger en .srt, sont sur le site d’UniversalSubtitles.org.
À partir de cette page, on peut rajouter simplement des sous-titres dans d’autres langues, calés sur la VO. Ça veut dire qu’une fois la transcription faite et synchronisée, en anglais ou autre, la traduction en français est vraiment simplifiée : on a juste à la rentrer dans les cases en dessous de chaque ligne de sous-titres de la langue originale. On peut bien sûr la stopper puis la reprendre plus tard. On voit également sur cette page les langues disponibles liées à la vidéo et l’avancement des traductions.
Bref, c’est vraiment du sous-titrage collaboratif. Les outils sont minimalistes mais efficaces. On peut tout ré-éditer, sauvegarder, exporter. Et on peut même uploader un fichier .srt, pour ceux qui ont plus souvent l’occasion de traduire hors ligne plutôt que connectés à Internet.
Comme je l’ai déjà dit, les outils sont, pour le moment en tout cas, assez minimalistes. Par exemple on ne peut pas régler les sous-titres : la police, la couleur, l’emplacement… limitation du HTML5 ou pas encore implanté dans ce programme ? On verra. Mais ça risque de poser parfois des gros problèmes de visibilité des sous-titres. Il m’est arrivé à plusieurs reprises, sur les vidéos qu’on a placées sur Framatube, de devoir rajouter une bande noire en-bas, ou les placer en haut, pour pouvoir lire convenablement les sous-titres pour des raisons de contraste avec le fond, qui peut varier…
Un autre bémol, c’est qu’il faut s’enregistrer : il faut soit un compte Twitter, soit un compte OpenID, soit un compte Google… En fait ça ne crée pas de compte à proprement parler, mais se sert de l’existant, ce qui est vraiment un moindre mal.
En tout cas c’est un bel outil qui va nous rendre bien des services pour nos sous-titrages.
Test fait avec une vidéo de Fred Couchet, de l’April, vidéo hébergée sur Blip.tv : http://universalsubtitles.org/videos/JFyBckvaWyCE/fr/
( {"base_state": {"language": "fr"}, "video_url": "http://blip.tv/file/get/Framasoft-FredericCouchetLeRoleDeLAPRILAuxMunicipalesDe2008975.ogv"} )
[1] Le Framablog de Framasoft, qui publie les travaux des projets Framatube et Framalang, tout cela n’est pas sans rappeler un certain Batman, avec sa Batmobile garée dans sa Batcave… Mais nous nous éloignons déjà du sujet.
Voici, révélé sur son blog par Bradley M. Kuhn (cadre dirigeant à la FSF impliqué dans le projet GNU), l’un des meilleurs ingrédients pour la réussite d’un projet de logiciel libre : rendre son développement public, dès la conception. C’est du moins l’enseignement qu’il retire d’un échange qu’il a eu avec Loïc Dachary, pionnier du logiciel libre, fondateur de la FSF France, d’EUCD.info ou encore de la plateforme d’hébergement de projets libres Gna! [1].
Or, si l’idée peut sembler simple, sa réalisation est loin d’être anecdotique et porte à de nombreux débats, comme le synthétise ici Bradley. Mais surtout, ce qui se dessine au travers de cette réflexion, c’est un élément fondamental de la définition de ce qu’est un projet libre, un projet ouvert, un projet pérenne : c’est un projet dont on partage les idées et la conception, en plus des sources. Bradley Kuhn oppose, en filigrane, à cette vision, celle de grands projets (qui se clament bien souvent eux-même « OpenSource ») dont en effet seul le code est publié. Des projets opposant une résistance aux contributions extérieures, et qui peuvent alors presque paradoxalement sembler hermétiques, fermés…
Plusieurs exemples viennent aisément en tête car c’est entre autres l’un des principaux reproches fait à Chromium, la version « OpenSource » du navigateur Google Chrome. Mais LibreOffice, le récent fork d’OpenOffice, illustre parfaitement la conclusion de Bradley, quand la communauté d’un projet de logiciel libre finit par n’avoir d’autre choix que de partir sur un embranchement définitif des fichiers sources pour en ouvrir au public le développement, et plus le code seulement.
Bradley M. Kuhn – 11 juin 2010 – EBB.org
(Traduction Framalang : Barbidule, Loquemunaine, Goofy)
Il y a quelques années, j’avais envisagé de me lancer dans un projet de logiciel libre. Il n’a pas vu le jour, mais j’ai appris au passage des choses bonnes à savoir. Quand j’ai pensé à démarrer ce projet, j’ai fait comme à mon habitude : j’ai demandé à quelqu’un qui en savait plus que moi. J’ai donc téléphoné à Loïc Dachary, qui a initié de nombreux projets de logiciels libres, pour lui demander conseil.
Avant même que je puisse ne serait-ce qu’évoquer mon idée, Loïc m’a demandé : « Tu as une URL » ? J’étais abasourdi. Ben, je n’ai pas encore commencé, répondis-je. Bien sûr que si, reprit-il, puisque tu m’en parles c’est que tu as commencé. Le plus important, c’est que tu me dises où sont les octets.
Loïc m’expliqua ensuite que la plupart des projets échouent. Le plus difficile dans un projet de logiciel libre est de le pousser à un stade suffisamment avancé pour qu’il puisse survivre même si ses créateurs initiaux le quittent. Donc, selon la théorie de Loïc, la tâche la plus urgente à accomplir au démarrage d’un projet, c’est de générer ces octets, dans l’espoir qu’ils se fraieront un chemin jusqu’à une équipe de développeurs qui contribueront à maintenir le projet actif.
Mais qu’est-ce qu’il entend par « octets » au juste ? Il veut tout simplement dire que vous devez exposer vos réflexions, votre code, vos projets, vos idées, presque tout en fait sur une adresse publique où tout le monde pourra les voir. Montrez vos octets, montrez-les à chaque fois que vous en créez si peu que ce soit. C’est la seule chance de survie de votre projet de logiciel libre.
Le premier objectif d’un projet de logiciel libre est de rassembler des développeurs. Aucun projet ne peut avoir de succès à long terme sans une base diversifiée de développeurs. Le problème c’est que le travail initial de développement et le planning du projet finissent trop souvent enfermés dans la tête d’un petit noyau de développeurs. C’est dans la nature humaine : comment puis-je passer mon temps à expliquer à chacun ce que je suis en train de faire ? Si je le fais, quand trouverai-je le temps de faire vraiment avancer les choses ? Ceux qui dirigent les projets de logiciels libres savent résister à ce désir naturel et font ce qui peut sembler contre-intuitif : ils exposent leurs octets publiquement, même si cela les ralentit un peu.
Ce processus est d’autant plus nécessaire à l’ère des réseaux. Si quelqu’un veut créer un programme qui remplisse sa mission, son premier outil est le moteur de recherche : il s’agit de savoir si quelqu’un d’autre a déjà fait le boulot. L’avenir de votre projet dépend entièrement du fait que chaque recherche de ce type aide des développeurs à découvrir vos octets.
Début 2001 j’ai demandé à Larry Wall quel était le projet le plus difficile parmi tous ceux sur lesquels il a travaillé. Sa réponse fut immédiate : "quand j’ai développé la première version de Perl5," m’a dit Larry, "j’avais l’impression que je devais coder tout seul et le faire tourner par mes propres moyens". Bien sûr, Larry est un gars tellement doué qu’il peut se permettre de créer à lui tout seul un programme que tout le monde voudra utiliser. Bien que je ne lui aie pas demandé ce qu’il ferait aujourd’hui dans une situation pareille, je devine – particulièrement quand on voit comment le développement de Perl6 est devenu public – qu’il utiliserait plutôt les nouveaux outils en ligne, tels que DVCS, pour montrer plus vite et plus souvent ses octets, et chercher à impliquer plus tôt davantage de développeurs[3].
Il est vrai que la priorité de la plupart des développeurs est de tout cacher. "On publiera quand ce sera prêt", ou bien – pire encore – "le noyau dur de l’équipe travaille bien ensemble ; rendre le projet public maintenant ne ferait que nous ralentir". En vérité, c’est un mélange dangereux de peur et de narcissisme, exactement la même pulsion que celle qui pousse les développeurs de logiciels non-libres à les conserver propriétaires.
Les développeurs de logiciels libres ont la possibilité de dépasser la réalité fondamentale de tout développement logiciel : le code est mal fichu, et n’est généralement pas terminé. Malgré tout, il est essentiel que la communauté puisse voir ce qu’il se passe à chaque étape, dès le noyau initial du code et au-delà. Quand un projet est perçu comme actif, cela attire les développeurs et donne au projet une chance de succès.
Quand j’étais à la fac, une des équipes d’une classe de génie logiciel s’est complètement plantée. C’est arrivé alors même qu’un des membres de l’équipe avait passé près de la moitié du semestre à coder par lui-même, nuit et jour, sans se soucier des autres membres de l’équipe. Durant l’évaluation finale, le professeur lui fit remarquer : « un développeur de logiciel, ce n’est pas un pilote de chasse ». L’étudiant, ne voyant pas le rapport, plaisanta : « Ouais, je sais, au moins le pilote de chasse, il a un copilote ». En vérité, il ne suffira pas d’une personne ou deux, ou même d’une petite équipe, pour faire aboutir un projet de logiciel libre. Le projet ne marchera que s’il est soutenu par une communauté importante qui évitera tout point individuel de défaillance.
Il n’en reste pas moins que la plupart des projets de logiciels libres sont voués à l’échec. Cependant, il n’y a aucune honte à balancer quelques octets, pour inciter les gens à y jeter un oeil, quitte à laisser tomber si la mayonnaise ne prend pas. Toute la recherche scientifique fonctionne ainsi, et il n’y a pas de raison pour que l’informatique fasse exception. Garder un projet privé, c’est garantir son échec ; le seul intérêt, c’est que vous pouvez dissimuler le fait que vous avez essayé. Comme le disait mon directeur de thèse lorsque je me faisais du souci quant à la réussite de ma recherche : un résultat négatif peut être aussi intéressant qu’un résultat positif. Ce qui est important, c’est d’être sûr que tous les résultats seront publiés et que le public pourra les examiner.
Quand j’ai commencé à parler de cette idée il y a quelques semaines, certains m’ont répondu que les premiers programmes GNU, les logiciels fondateurs de notre communauté ont d’abord été développé en privé. C’est vrai, mais le fait que les développeurs du projet GNU aient procédé de cette façon ne veut pas dire que c’est la bonne. Nous disposons désormais des outils pour faire facilement du développement en public, et nous devrions le faire. De mon point de vue, aujourd’hui nous ne sommes pas vraiment dans l’esprit du logiciel libre tant que le projet, y compris les discussions sur sa conception, les plans et les prototypes, ne sont pas développés publiquement. Le code (quelque soit sa licence) qui n’est que balancé à intervalles plus ou moins réguliers mérite d’être repris par une communauté qui rende son développement public.
Mise à jour (2010-06-12) : J’ai complètement oublié de parler de « The Risks of Distributed Version Control » par Ben Collins-Sussman, qui date de cinq ans maintenant mais qui est toujours d’actualité. Ben fait un constat similaire au mien, et remarque que certaines utilisations de DVCS peuvent avoir les effets que j’encourage les développeurs à éviter. Je pense que DVCS est comme n’importe quel autre outil : il peut être mal utilisé. Il faut éviter de s’en servir comme Ben le signale, et DVCS, lorsqu’il est utilisé correctement, aide dans le processus de développement public de logiciel.
[1] Fonctionnant tout comme GNU Savannah grâce au logiciel Savane dont il est le principal développeur.
[2] Crédit photo : Steve Jurvetson (Creative Commons By). Cette photo, intitulée « mémoires primitives » est un gros plan sur une barrette de mémoire vive du milieu du siècle dernier. On y voit un quadrillage de « fins » fils de laiton, tricoté à la main avec de petits anneaux de ferrite à chaque intersection, le tout noyé dans de la colle. L’ensemble, qui pouvais occuper le volume d’un magazine papier, était capable de conserver plusieurs centaines de … bits de mémoire. Le circuit tricoté ici représente ainsi 38 octets de mémoire vive, et il est assez vertigineux de constater que 50 ans plus tard, on stocke environ 25 millions de fois plus d’information dans le volume de chaque anneau de ferrite.
[3] Notez que rendre son code public au milieu des années 1990 était plus difficile (d’un point de vue technologique) que maintenant. Ceux qui n’ont pas connu les archives shar ne s’en rendent pas compte. 🙂
Avec un peu de retard cette semaine, voici le traditionnel billet Geektionnerd, qui revient cette fois sur le « virus » d’un nouveau genre ayant frappé le site web Twitter.com la semaine dernière.
Cette faille de sécurité se matérialisait par un « tweet », donc un message textuel de 140 caractères maximum, perdu dans le flot des autres messages du genre sur le site Twitter.com, et ne comportant dans sa partie visible que des cases noires à la place des lettres. Bien loin d’êtres inquiétantes, ces cases noires attisaient la curiosité des lecteurs, car de nombreux tweets artistiques profitent en effet des possibilités offertes par Unicode pour afficher des dessins, des partitions de musique ou encore cacher des messages… Seulement là, au survol des cases noires par la souris, un code JavaScript en partie embarqué dans le tweet s’exécutait, postant le tweet malicieux sur votre compte à votre place, et exposant ainsi vos amis. Le « virus » s’est alors répandu très vite, et jusque sur le compte Twitter de Framasoft…
Moralité, en tant que défenseur du logiciel libre, Framasoft vous recommande de suivre son compte Identi.ca plutôt que son compte Twitter 🙂
Crédit : Simon Gee Giraudot (Creative Commons By-Sa)