Sogilis

Passionate people, great software

[sogilisblog]

pure.js : template engine without markup

Ces derniers dojo, on a vu des langages vraiment sympa : Clojure avec OM et Elm. Par contre, il y a un petit truc qui me chiffonne : les templates.

Autant faire du template en Lisp, ça passe assez bien. C'est fait pour ça. Mais avec Elm, ce n'est vraiment pas joli (mon opinion seulement). D'un point de vue propreté, je serais plus à l'aise avec du markup séparé du code. Comme ce qu'on faisait en xHTML à l'époque où ça existait. Le mantra c'était : séparer la logique (js) de la sémantique (html) de la présentation (css). Et j'aime toujours ce mantra.

Pour vous aider à cette séparation, je vous propose pure.js, un moteur de template sans markup.

C'est du HTML sans même un attribut spécifique.

Comment ça marche ?

Soit la structure JSON est très proche du markup : pure.js va directement remplir les balises HTML avec le contenu du JSON.

Soit la structure est un peu différente – comme c'est souvent le cas si le JSON n'est pas spécifique au markup : on a un JSON intermédiaire qui permet de dire à quel nœud HTML chaque objet JSON doit être mappé. Le mapping se fait avec des sélecteurs CSS.

Allez voir, il y a un exemple simple en haut pour comprendre comment ça marche.

Dans la même veine, il existe aussi Weld. Il a cependant l'air moins puissant.

Shanti

[sogilisblog]

De tout, de rien, des bookmarks, du bla bla #2

Yves Brissaud _crev_ eunomie +YvesBrissaud

[sogilisblog]

De tout, de rien, des bookmarks, du bla bla

Petit aperçu commenté de notre veille de ces derniers jours. Le principe n'est pas de vous fournir une suite de lien mais plutôt que ces liens racontent une histoire, ce qui nous intéresse ou nous interpelle. Mais tout de même, pour les plus pressés, la liste de l'ensemble des liens est dispo à la fin de l'article.

Un peu de contenu

Méthodes, langages et bonnes pratiques

S'il est un point qui nous tient vraiment à cœur, c'est celui d'écrire du code maintenable et qui tende à comporter le moins (zéro si possible) de bugs.

Si on prend l'aspect maintenabilité, il existe en réalité différentes visions qui s'affrontent ou se complètent selon les cas. Si on prend le développement objet il y a tout ce qui tourne autour d'Object Calisthenics, de SOLID par exemple.

Néanmoins, il existe d'autres approches. Un article que j'ai lu cette semaine apporte un autre éclairage sur le sujet, très pragmatique j'ai trouvé et très en accord avec les pratiques que nous mettons en place dans divers projets : Write code that is easy to delete, not easy to extend. C'est un article que je vous recommande vraiment de lire.

Et pour illustrer un peu plus le principe, je vais juste vous parler de ce que nous avons réalisé dans un projet actuel. Pour placer un peu le contexte, nous participons au développement des applications mobile d'Hexo+, une caméra volante autonome. Vous comprendrez donc que la sécurité est un sujet hautement critique. Lorsque nous avons entrepris de refondre toute la gestion des alertes (l'ensemble des actions à réaliser lorsque le drone n'a plus de batterie, de GPS, perdu la connexion, etc.) il s'agissait de faire cela de la meilleure manière et avec le moins de régressions possibles. La solution classique aurait été de se lancer petit à petit dans un refactoring des classes concernées, de transformer le comportement jusqu'à avoir quelque chose qui convienne à nouveau. Sauf que cela représente un très gros travail, plutôt en mode big bang (le logiciel devient inutilisable tant que cela n'est pas terminé). Au contraire, nous avons commencé… par ne rien toucher ! Nous avons monté une deuxième architecture de gestion des alertes en parallèle. Pendant un temps, les deux systèmes fonctionnaient d'ailleurs de concert. Puis, lorsque le nouveau système s'est avéré suffisament avancé, nous avons simplement débranché et supprimé l'ancien. Au final, nous avons portés la notion de maintenabilité et d'évolutivité non pas au niveau des objets, mais bien au niveau du système (ce qui compte au final). Mais, et c'est aussi le propos de l'article, cela n'est possible que si nous sommes capables de supprimer l'ancien code. Plus ce code sera dur à supprimer (parce qu'il est présent partout, parce qu'il est mal découpé, etc.) plus la tâche sera ardue.

Ecrire un code qui pourra facilement être supprimé est l'une des choses les plus importantes pour faire évoluer en douceur un système entier.

Une fois que vous êtes dans cette optique, il vous reste à écrire du code qui réalise réellement ce qu'on attend de lui. Et là… c'est loin d'être simple.

Prenons un exemple qui d'apparence est trivial :

Étant donné une liste de valeur et une valeur, retourne l'index de la valeur dans la liste ou indique qu'elle n'est pas présente dans la liste.

Je suis certain que vous avez déjà réalisé un code du genre. Et que ça n'a pris que quelques lignes. Facile. Maintenant, que vous indique votre code en terme de documentation, de robustesse aux cas limites, de spécifications, de garanties d'exécution normale, etc. ? Vous pensez que votre code est bon ? Je vous suggère dans ce cas d'aller tout de suite lire cet article sur les Tests vs Types et vous devriez voir qu'en réalité c'est loin d'être trivial. Et lorsqu'on voit l'effort qui peut être nécessaire pour un code d'apparence si simple, que penser d'un code plus complexe ?

Si vous voulez d'ailleurs aller un peu plus loin, vous pouvez aller lire ce tutoriel à propos de SPARK 2014 qui tente de répondre à exactement la même spécification, cette fois ci en allant jusqu'à la preuve. Très instructif encore une fois du travail nécessaire pour garantir qu'une si petite portion de code fera bien ce qui a été demandé.

Histoire de rester dans des sujets connexes, connaissez-vous la règle numéro 1 des choses à ne pas faire de Joel Spolsky ?

Rewrite your software from scratch

David Heinemeier Hansson (créateur de Ruby on Rails, Basecamp, etc.) n'est quant à lui pas d'accord. Et il vous explique pourquoi (et comment ils ont réécrit plusieurs fois Basecamp) dans cette vidéo.

JavaScript

Si vous avez déjà fait du javaScript (What else?), vous avez nécessairement été confronté à la problématique de bind et au fait que this n'a pas le même comportement que dans la plupart des langages habituels. Après pas mal de bricolages, on est arrivé à avoir une solution correcte en ES5 :

$('.some-link').on('click', view.reset.bind(view))

Avec la méthode bind présente sur les objets on peut ainsi s'assurer que la méthode reset de view sera bien appelée sur l'objet view et non sur l'objet DOM derrière $('.some-link'). Cette méthode bind est quand même une grande avancée. Mais ES7 va encore plus loin (même si ce n'est pour le moment qu'une proposition) :

$('.some-link').on('click', ::view.reset)

L'introduction de l'opérateur :: réalise justement la même chose que le bind précédent avec une plus grande lisibilité et de manière un peu moins verbeuse. Si vous voulez en savoir un peu plus sur cet opérateur (qui ne fait pas que le bind), je vous suggère d'aller lire cet article.

Toujours du côté des nouveautés Javascript, si vous avez un peu suivi ce qui se passe depuis quelque temps (ok, ces dernières années en fait), le code que nous écrivons est de plus en plus tourné vers de l'asynchrone (parfois à l'excès malheureusement). Et qui dit code asynchrone dit souvent code difficile à tester. C'est sur ce point qu'une nouvelle bibliothèque de test est sortie avec pour nom le très explicite painless. Elle nous promet d'être plus rapide et surtout de faciliter le test du code contenant des promises, async/await, generators et autres nouveautés ES6/ES7.

Sur le même segment est aussi apparu AVA de Sindre Sorhus. Plus rapide, adaptée à toutes les nouveautés du langage mais aussi avec le point particulier d'exécuter les tests en isolation pour éviter tout effet de bord et s'adapter au matériel actuel pour de meilleurs performances.

Clojure

Chez Sogilis, nous utilisons de nombreux langages différents. Et s'il en est un qui sort un peu du lot par son style c'est bien Clojure. Fonctionnel, bourré de parenthèse (Lisp signifie bien Lots of Irritating Single Parentheses, non ?) mais tellement expressif et concis qu'il est difficile de ne pas tomber sous le charme :-)

Et justement, si vous vouliez savoir comment il est possible de passer d'un magnifique amas de ces parenthèses à un bytecode pour JVM (et que vous avez quelques heures devant vous…), voici un magnifique article sur le sujet : Clojure Compilation: Parenthetical Prose to Bewildering Bytecode.

Toujours à propos de Clojure, voici un petit tutoriel très bien amené qui présente comment réaliser une interface d'administration de blog à base de Om et de ClojureScript. Om est un binding ClojureScript pour react. Le code présenté est plutôt intéressant, ce que j'ai apprécié est la concision et la facilité de traitement des requêtes asynchrones, un peu comme on ferait avec async/await en ES7, mais ici au travers de channels et, surtout, sans promises. Finalement comme si on utilisais des goroutines.

S'il est une notion centrale à clojure et l'ensemble des langages fonctionnels, c'est bien l'immutabilité. Néanmoins, savoir l'expliquer simplement n'est pas toujours aisé. Voici un article qui se propose d'expliquer l'immutabilité à partir d'un post de blog. Plutôt réussi, il devrait vous permettre de comprendre la base ou de la faire comprendre facilement.

Go

Un autre des langages plutôt en vogue par chez nous est Go. Un point qui peut être déroutant au début lorsqu'on vient de Ruby, Node.js ou autre est l'absence d'un gestionnaire de paquet dédié au langage. Et lorsque je lis So you want to write a package manager je me dis que finalement c'est très (très) loin d'être trivial. Mais cela permet aussi de mettre en exergue les problèmes que d'autres gestionnaires peuvent avoir (bien que parlant de Go, cet article est très généraliste). Par exemple, bower n'avait pas d'équivalent aux fichiers de lock permettant de reproduire une installation d'un poste à l'autre.

A l'autre bout de la chaine, il y a l'exécution et la mise à jour des programmes. overseer est une bibliothèque qui agit sur cette partie critique en production : monitorer, redémarrer et mettre à jour des binaires Go. Attention, il n'est pas encore à un stade utilisable en production (ou à vos risques et périls) mais à surveiller et garder sous le coude dès qu'il sera prêt.

Je ne sais pas si on vous l'a déjà dit, mais à Sogilis on aime bien Git. A tel point d'ailleurs qu'on donne des formations sur le sujet depuis des années. Et à tel point aussi qu'on l'utilise dans nos applications, y compris en tant que base de données. Sur le marché, en général la solution est d'utiliser un binding au dessus de la libgit2. La plupart des langages en ont, Go y compris. Néanmoins, une nouvelle bibliothèque a vu le jour récemment, et elle ne se base justement pas sur libgit2. Attention tout de même, elle n'est faite que pour de la lecture, il n'y a pas d'écriture possible avec. Il s'agit de go-git et elle est utilisée par source{d} qui entre autre analyse l'ensemble des dépôts de github ! A tester plus en avant et voir ce que ça apporte réellement de plus (ou de moins) que le binding Go qui existait déjà.

Sécurité

Un point toujours central dans la sécurité de nos applications est la manière dont on stocke et compare les mots de passe. Hors de question ici de les garder en clair dans une base ! Par contre, régulièrement les bonnes pratiques changent ou, simplement, de nouvelles bibliothèques apparaissent pour nous faciliter la vie (et hors de question ici de réinventer la roue). Voici donc un article qui vous présente les bonnes manières de stocker un mot de passe en 2016 et ceci dans 6 langages différents.

Divers

En tant que développeur, nous avons souvent tendance à nous cacher derrière la technique, derrière la création d'outils et non leur usage. Pourtant, il est nécessaire d'avoir conscience que l'usage fait de nos développements peut avoir des impacts non négligeables, autant dans des bons que des mauvais côtés. C'est (une partie au moins) du message que Stéphane Bortzmeyer a tenté de faire passer lors du Mix-IT 2015.

Dans un tout autre registre, regardez comment un réseau de neurones entraîné sur des milliers de photos arrive à coloriser des images noir et blanc. C'est fascinant et plutôt juste comme résultat !

Et comme on apprécie les Lego, on ne peut que rester admiratif devant cette machine tout en Lego qui plie et lance un avion en papier !

Liste des liens

Méthodes, langages, etc.

Write code that is easy to delete, not easy to extend

Tests vs Types

Spark tutorial

Javascript

Funcion Bind Syntax

Painless Javascript Testing

AVA Futuristic test runner

Clojure

Clojure Compilation: Parenthetical Prose to Bewildering Bytecode

Om

ClojureScript: Real world app

Explaining immutability

Go

So you want to write a package manager

overseer

libgit2

go-git A low level and highly extensible git client library

Sécurité

How to safely store password in 2016

Divers

[Mix-IT 2015] Come to the dark side de Stéphane Bortzmeyer

Re-pigmentation de photographies

Lego Paper Plane Machine

Yves Brissaud _crev_ eunomie +YvesBrissaud

[sogilisblog]

Victor se lance dans l'entrepreneuriat

Depuis le 4 février 2013, on a pris l’habitude de retrouver Vicky tous les matins avec plaisir. En stage de fin d'études à l'Ensimag puis en CDI au sein de la Sogiteam durant deux ans, il s'envole aujourd’hui pour monter sa boîte. Victor, c'est 26 ans de vitamines : il est co-organisateur du Startup Weekend Grenoble et des HumanTalks, ces conférences proposées par les développeurs pour les développeurs tous les mois dans les villes de France. Et comme il a plusieurs cordes à son arc, quand il ne fait pas le poisson dans l’eau, il est capable de gravir le Mont-Blanc !

Le virus de l'entrepreneuriat l'a piqué lors de la première édition du Startup Weekend Grenoble. Depuis, il a enthousiasmé un bon nombre de clients, s'est creusé les méninges et a fortement contribué à la banane de l'équipe. Retour sur ces 2 bougies soufflées à Sogilis et mise en lumière de ses perspectives !

Victor, quels sont tes projets ?

Mon projet est de créer ma boite dans le domaine de l'informatique. Je souhaite sortir du modèle de service pour m'essayer à celui du produit, qui a un potentiel plus exponentiel. J'ai décidé de prendre le temps de tester et de rencontrer de nouvelles personnes. Cela passe par la création, aussi bien au niveau humain, avec des associés à trouver, et au niveau technique. J'ai envie de me diversifier, d'être pertinent au-delà de la technique : l'idée d'avoir plusieurs casquettes me plaît.

Pour le moment, je développe une solution qui permet de redonner la clé de la vie privée à l'utilisateur qui stocke des documents dans le cloud. Il n'aura plus à se soucier de la confidentialité des données qu'il stocke, des photos de vacances aux documents sensibles en entreprise. Nous sommes aujourd'hui 3 sur ce projet appelé DataLords, et nous souhaitons sortir une première version de la solution à la fin de l'année.

Qu'est-ce qui t'a poussé à devenir entrepreneur ?

J'ai tout de suite accroché au dynamisme de l'écosystème grenoblois autour de l'entrepreneuriat. Cela m'a convaincu qu'on peut partir d'une idée et la mener à un produit viable avec une équipe. Je me sens aujourd'hui prêt à relever ce challenge. 

Que retiens-tu de tes 2 ans à Sogilis ?

La confiance est un facteur nécessaire pour la réussite de toute entreprise. Sogilis montre que des modèles différents de management existent et valent le coup d'être retestés. L'environnement favorise le bien-être des personnes qui nous entourent et entraîne automatiquement un vrai gain de motivation et d'envie. Cela permet de produire plus et surtout mieux, avec moins de ressources. Finalement, je retiens que le travail peut être un vrai plaisir.

Je me sens assez solide avec cette expérience de 2 ans pour me lancer. J'ai toujours considéré Sogilis comme une étape pour apprendre. Je considère que c'est une réussite, ces deux ans sont un véritable tremplin pour la suite.

Quel est ton souvenir le plus parlant à Sogilis ?

La première fois que j'ai pris la voiture de Sogilis pour aller voir un client, j'ai fait le plein. L'essence à la place du diesel, c'était de la haute voltige !

Plus sérieusement, un de mes plus beaux souvenirs est une semaine de télétravail en binômage à Istanbul et à Barcelone. De Sogilis, je retiens l'envie de partager et de transmettre. Cela m'a tout de suite impressionné : il y a un effort de transmission d'une personne à une autre. Cela vaut en interne et avec les clients, que l'on cherche à rendre autonomes. Pour rebondir sur l'autonomie, c'est quelque chose que je recherchais, même si je ne connaissais pas véritablement la signification: prendre des décisions, être responsable. Aujourd'hui, la dépendance à un collaborateur est quelque chose que je ne peux plus envisager. Pour la start-up 3DKF, nous sommes passés d'un brevet à une solution industrielle, jusqu'au transfert de compétences chez le client. Pour moi, c'est génial dans le sens où j'ai tout vu sur un projet. Même si ce dernier évolue et va continuer, j'ai fait une boucle complète. J'estime que c'est une énorme valeur pour créer ma boîte.

Enfin, parmi les faits marquants, j'ai instauré le mini golf, le premier bureau debout et la balle de grossesse au sein des locaux.

Qu'est-ce qu'on peut te souhaiter ?

De continuer à m'éclater, tout simplement.

Bonne route Vicky ! 

[sogilisblog]

Demystifying Git: 3 Concepts to Do Everything with Git

Simon Denier simondenier sdenier +SimonDenier

[sogilisblog]

Demystifying Git: 3 Concepts to Understand the Git Model

Simon Denier simondenier sdenier +SimonDenier

[sogilisblog]

Mon intégration au sein de Sogilis : bilan après un mois

Il y a quelques années, j’aspirais à mieux gérer mon temps et à prendre ma vie en main. En parcourant des blogs, des articles et des livres, j’ai été séduit par les valeurs et la conception de la vie de certains auteurs.

À la fin de l’année 2014, juste après mon diplôme, je fais le choix de chercher l’entreprise qui correspond réellement à mes valeurs et à mes aspirations. Alors que mon entourage me soutient sans être absolument convaincu du réalisme de ma recherche, je pense l’avoir trouvée en janvier. Je ne connais rien des entreprises libérées mais les témoignages de ses salariés me font sauter le pas sans inquiétude. Voilà mes premières impressions après un mois ici.

We’re not slacking off. Our code is compiling.

Chez Sogilis, on peut être soi-même, et cela se ressent dès l’arrivée dans l’entreprise. J’ai la sensation que grâce à une structure horizontale, sans relations hiérarchiques, les échanges sont plus vrais et sincères. Il n’y a pas de faux semblant et c’est très agréable d’évoluer dans ce contexte. On se réfère à ce qu’on entend, puisqu’on est honnête. Cela permet de communiquer sans barrière et de résoudre les conflits entre nous rapidement.

La confiance qu’on place en nous est vraiment motivante. Alors que d’ordinaire, ce sont surtout des projets personnels qui me passionnent et qu’en entreprise les développeurs sont plutôt considérés comme des “petites mains”, j’ai découvert une société où le travail est véritablement gratifiant. Nos connaissances peuvent apporter à un projet et le faire évoluer. Du coup, on a envie d’aller toujours plus loin que la simple exécution : on est responsable des choix qui vont guider le projet. Par exemple, on accompagne le client pour mieux cerner son besoin et lui faire économiser certaines fonctionnalités inutiles. L’implication est d’autant plus forte.

C’est un développeur de Sogilis qui m’a présenté cette entreprise atypique lors d’un événement. Cette originalité est présente dès le recrutement car il est mené par les équipes. C’est tellement plus logique que les futurs collègues soient ceux qui rencontrent les candidats. En effet, si on veut que l’ambiance de travail soit bonne, en quoi imposer une personne sans qu’elle n’ait été confrontée à l’équipe serait une bonne idée ? Travailler ensemble, c’est aussi et surtout une histoire de feeling. Être sélectionné par les développeurs me paraît être un gage de réussite pour la suite. Pour ma part, ils ont estimé que j’étais capable de m’intégrer et qu’on était sur la même longueur d’ondes, malgré des profils différents. Le candidat doit passer un test en collaboration lors de l’entretien. Cet exercice de binômage permet de voir comment il se comporte en codant avec l’équipe sur un point technique. Il ne s’agit pas de montrer des compétences sur une technologie particulière, mais plutôt de tester la capacité à apprendre et à analyser. Cela change des questionnaires pointus sur une compétence. Je pense avoir été recruté car je suis très sensible à la méthode de fonctionnement de Sogilis et partage ses valeurs. Je suis dans l’entreprise depuis un mois et j’apprends tous les jours : rien qu’en discutant avec l’équipe de points techniques, je m’enrichis.

Présentation du projet de voiture autonome par Graham

Au début, j’ai beaucoup tâtonné car on ne m’avait jamais donné autant d’autonomie. Au bout d’une semaine, un membre de l’équipe dirigeante m’a proposé un premier entretien afin de savoir si tout se passait bien. À ce moment-là, je me demandais encore ce qu’on attendait de moi et j’avais des difficultés à prendre des initiatives. J’avais une attente managériale forte car c’était la vision du monde du travail que je connaissais. Cet entretien m’a convaincu de la nécessité de m’impliquer dans les projets qui m’intéressaient, d’aller me renseigner sur ce qu’il était possible de faire. On nous pousse à être proactifs, ce qui est d’autant plus vrai car on choisit les projets sur lesquels on travaille. Je l’avais compris à demi-mot, sans saisir l’ampleur de cette liberté. On s’investit avec le client en cherchant la vraie valeur ajoutée que l’on peut lui apporter. Aucune direction n’est guidée par un commercial, on travaille donc sur les projets pour lesquels on se sent pertinent.

Rien que le fait d’avoir pu être autonome dès la première semaine est étonnant : la confiance est naturellement accordée. Je n’ai personne sur mon dos alors que je n’ai pas encore fait mes preuves. On a vraiment envie d’être digne de cette confiance. C’est totalement bien vu de finir tôt un jour, on s’adapte librement aux besoins sans contrainte extérieure tant que l’on est productif. En fonctionnant en mode agile et grâce à des itérations de 2 semaines, on connaît précisément nos objectifs à court terme : on sait toujours si on est dans les clous.

Il y a une notion de plaisir au travail qui est très présente, ne serait-ce que ces derniers jours où j’ai rencontré un problème plutôt coriace. Je me suis avant tout lancé un défi. Si aujourd’hui je suis à un stade incertain, je sais que dans quelques jours je pourrais faire le point et constater les avancées. Être libre dans la gestion des projets permet d’aller au-delà de ce qu’on attend de nous : on s’impose nos propres limites et réalisons des challenges pour les dépasser. Ces exigences sont enrichissantes.

L’équipe de Sogilis est composée de personnes qui restent elles-mêmes. Il n’y a pas de jugement de valeur sur la manière d’être de quelqu’un ou de limites de bienséance. Je trouve ça vivant, je suis une personne qui aime bien lâcher prise. Quand j’entends un cri à l’autre bout du bureau ou quand il y a une bataille de Nerf [NDLR : des pistolets en jouet], cela me met de bonne humeur. J’apprécie l’ambiance bon enfant, et c’est possible de travailler efficacement dans ces conditions. En effet, on fait du travail de qualité, c’est ce que l’on attend de nous : cette atmosphère est motrice.

Sortie buggy sur glace. Invité avant le premier jour de travail. Une super occasion de rencontrer ses futurs collègues. On se sent très vite intégré !

J’ai eu une période de chômage parce que je voulais trouver l’Entreprise avec un grand E, du coup j’ai commencé un projet en parallèle avec un ami. Je sais qu’il est possible d’entreprendre ici. Si l’idée est en stand-by depuis mon embauche et la sienne, l’opportunité de continuer ce projet en étant à Sogilis reste ouverte. Aujourd’hui, je veux apprendre de la collaboration avec mes collègues tout en me considérant pertinent. Tant que j’aurai cet équilibre, je n’aurai aucune raison de partir, car le gain sera mutuel. Aller au travail avec envie, c’est la plus belle des motivations. 

[sogilisblog]

Lecture d’un fichier Google Sheet en Ruby avec OAuth 2

Pour un développeur, piloter des Google Docs depuis son application est une fonctionnalité relativement puissante. Les API Google permettent beaucoup de choses en ce sens. En revanche, ce n'est pas toujours facile de s'y retrouver dans les méandres des différentes technologies, API et documentations que l'on peut trouver sur la toile. Suite aux difficultés que j'ai pu rencontrer en cherchant une documentation claire, je vais essayer ici de synthétiser les différentes étapes permettant de réaliser une opération assez fondamentale : lire le contenu d’un document Google Sheet en utilisant une connexion authentifiée avec OAuth 2 en mode server to server.

Pour les pressés, voici le code Ruby qui fait le boulot :

require 'rubygems' require 'google/api_client' require 'google_drive' # Get following info from Service Account created at # https://code.google.com/apis/console account_email = '[email protected]' key_file = 'private-key-for-xxxxxx.p12' key_secret = 'notasecret' key = Google::APIClient::KeyUtils.load_from_pkcs12(key_file, key_secret) client = Google::APIClient.new(   :application_name => 'my_application_name',   :application_version => '0.0.1') client.authorization = Signet::OAuth2::Client.new( :token_credential_uri => 'https://accounts.google.com/o/oauth2/token', :audience => 'https://accounts.google.com/o/oauth2/token', # Following scope defines which services you will be authorized to access :scope => 'https://www.googleapis.com/auth/drive ' + 'https://spreadsheets.google.com/feeds/', :issuer => account_email, :signing_key => key) # Request a token for this service account client.authorization.fetch_access_token! token = client.authorization.access_token session = GoogleDrive.login_with_oauth(token) # Read Spreadsheet document_id = "xxxyyyzzz" # Key attribute in Google drive url ws = session.spreadsheet_by_key(document_id).worksheets[0] puts ws[1,2] # Write content of cell A2

Mais passons à la première étape : l’authentification.

Authentification avec OAuth

La première difficulté est de comprendre les mécanismes du protocole OAuth 2.0 utilisé par Google, Facebook… Pour schématiser – beaucoup –, le principe consiste à récupérer un jeton (représenté par une chaîne de caractères) qui permettra ensuite d’interroger les services google sous une certaine identité pendant une durée définie. De nombreux articles expliquent cette techno en détail, notamment celui-ci : « Comprendre OAuth2 ». 

A noter : Google propose aussi une authentification par OAuth 1.0, mais la déconseille, même si elle est encore largement utilisée.

Histoire de ne pas réinventer la roue, nous allons utiliser la gem ruby gem google_drive pour l'authentification. Elle permet d’accéder aux documents Google Drive par la même occasion. En revanche, l’exemple donné par cette gem passe par une étape où l’utilisateur doit rentrer un code d’activation.

En effet, il faut bien comprendre que le protocole OAuth 2.0 est principalement employé lorsqu’un utilisateur souhaite qu’un site web tierce puisse utiliser son compte pour accéder à ses données. Dans ce cas de figure, lorsque l’utilisateur réalise l’action concernée sur le site web A, une page de connexion s’affiche demandant login et mot de passe du site web B. Ces informations permettront au site web A d’utiliser les services du site B sous l’identité de l’utilisateur.

Bien souvent, vous remarquerez qu’une liste de services est affichée sur cette page de login. Ces derniers correspondent au périmètre d’autorisation (cf. attribut « scope » plus bas) du jeton renvoyé.

Tout ceci est bien joli, mais nous cherchons une authentification « serveur à serveur », donc sans interaction de l’utilisateur, comme pendant l’exécution d’un batch par exemple.

Il n’y a pas 36 solutions, il faut utiliser un compte de service, et Google propose justement ce type de comptes (cf. documentation google). Ces comptes, destinés à être utilisés uniquement par des services, correspondent à des traitements serveurs. Ils sont rattachés à de vrais comptes utilisateurs, sachant que chaque utilisateur peut en créer plusieurs. Pour en créer un, il faut passer par la Google Developers Console comme ceci :

Créer projet

Menu API et authentification > API

Activer Drive API pour que notre compte de service puisse accéder aux services proposés par Google Drive

Menu API et authentification > Identifiants

Créer un identifiant client pour OAuth

Choisir Compte de Service : vous allez alors télécharger la clé privée (fichier .p12). Le mot de passe (notasecret) associé à cette clé sera alors affiché.

Notez ensuite l’identification client et l’adresse email du compte ainsi créé

Ensuite, il ne reste plus qu’à coder avec tous ces éléments :

Installation de la gem (google_drive)

sudo gem install google_drive

Ajout des librairies qui vont bien

require 'rubygems' require 'google/api_client' require 'google_drive'

Création de la clé d’activation avec le fichier .p12 et le mot de passe récupéré lors de la création du compte de service

key_file = 'private-key-for-xxxxxx.p12' key_password = 'notasecret' key = Google::APIClient::KeyUtils.load_from_pkcs12(key_file, key_password)

Authentification

client = Google::APIClient.new( :application_name => 'my_application_name', :application_version => '0.0.1') client.authorization = Signet::OAuth2::Client.new( :token_credential_uri => 'https://accounts.google.com/o/oauth2/token', :audience => 'https://accounts.google.com/o/oauth2/token', # Following scope defines which services you will be authorized :scope => 'https://www.googleapis.com/auth/drive ' + 'https://spreadsheets.google.com/feeds/', :issuer => account_email, :signing_key => key)

L’attribut « scope » contient les noms de domaine associés aux services Google auxquels on pourra accéder ensuite. Vous pouvez trouver la liste des scopes avec l’OAuth 2.0 Playground. Les autres attributs sont des valeurs fixes fournies par Google.

Récupération du jeton

client.authorization.fetch_access_token! token = client.authorization.access_token

Connexion avec ce jeton

session = GoogleDrive.login_with_oauth(token)

Il est temps de passer à la seconde étape, la juridiction.

Gestion des autorisations

Pour que notre compte de service puisse accéder à un fichier Google, il faut lui donner accès. Cette autorisation se fait de la même manière qu’avec n’importe quel autre utilisateur : action Partage. Par contre, il faut utiliser l’adresse email associée au compte : celle qu’on a noté lors de la création du compte de service.

Troisième étape : lecture du contenu.

Lecture de fichier Google Sheet

Enfin, pour lire un document, on peut vouloir le faire à partir de l'identifiant du document. On peut trouver cet identifiant dans l’url lorsqu’on édite le document dans son navigateur. Il correspond à l’attribut key. Prenons par exemple l’url suivante : 

https://docs.google.com/a/sogilis.com/spreadsheet/ccc?key=0Ag7vwNTdThiNdDNNecDYclUsMzZ1R0JpbXdUaERMUVE&usp=sharing#gid=0 

Dans ce cas, l’identifiant est : 0Ag7vwNTdThiNdDNNecDYclUsMzZ1R0JpbXdUaERMUVE

Grâce à la gem google_drive, nous pouvons lire le contenu de la Google Sheet relativement facilement :

document_id = "0Ag7vwNTdThiNdDNNecDYclUsMzZ1R0JpbXdUaERMUVE" ws = session.spreadsheet_by_key(document_id).worksheets[0] puts ws[1,2]

Ici, on va lire la cellule sur la 1ère ligne, 2ème colonne de la première page.

Il est aussi possible de modifier le document,

ws[1, 2] = “new value” ws.save

de récupérer le nombre de colonnes ou de lignes,

nbRows = ws.num_rows nbColumns = ws.num_cols

ou encore de rafraichir le document pour récupérer les modifications effectuées par d’autres utilisateurs :

ws.reload

Conclusion

Avec ce petit exemple, on a maintenant toutes les bases pour piloter des Google Sheets, mais pas seulement. On peut aller explorer l’API Google et essayer de piloter d’autres services comme Google Drive, Calendar… le tout en Ruby. De même, l'authentification avec un compte Google standard est identique.

[sogilisblog]

Ansible partie 3 : Les rôles

Dans notre précédent article, nous avons vu comment installer l'application ipfs sur notre serveur. Nous avons fait le tout de manière très simple, avec un playbook global. Cela est peu élégant si nous souhaitons déployer plusieurs services sur la même machine. Et comment faire pour découper une suite de tâches simples que nous voudrions pouvoir réutiliser ? La réponse à ces deux questions se trouve dans les rôles Ansible. Les rôles sont une manière un peu plus élégante d'inclure des tâches Ansible au sein d'autres tâches en déclarant des dépendances.

Transformer notre playbook en rôle

Commençons par créer un rôle simple correspondant exactement au playbook que nous avions la dernière fois :

--- - hosts: perrin   sudo: yes   tasks: - go-install: name=go-ipfs package=github.com/jbenet/go-ipfs/cmd/ipfs

Le rôle que nous allons créer va nécessiter de créer une arborescence dans un dossier roles/ qui va contenir notre role nommé ipfs :

roles/ipfs/tasks/main.yml :

--- - go-install: name=go-ipfs package=github.com/jbenet/go-ipfs/cmd/ipfs

Notre nouveau playbook va maintenant contenir une dépendance envers ce rôle :

--- - hosts: perrin   sudo: yes   roles: - ipfs

Un second rôle : cjdns-docker

Ce qui est intéressant, c'est d'avoir plusieurs rôles. Nous allons donc voir comment déployer cjdns en utilisant docker avec un rôle.

Ce rôle définit des variables dans roles/cjdns-docker/vars/main.yml :

--- name: cjdns

et se compose de tâches définies dans un fichier roles/cjdns-docker/tasks/main.yml :

--- - shell: docker pull mildred/cjdns - systemd-docker-service: name='{{name}}' - service: name='{{name}}' enabled=yes state=restarted - docker-datadir: name='{{name}}' volume=/etc/cjdns file=/cjdroute.conf register: cjdroute_conf - file: src='{{cjdroute_conf.file}}' dest='/etc/docker-{{name}}.conf' state=link

La variable name permet de nommer différents éléments du système correspondant au rôle. Elle a une valeur par défaut, mais pourra se redéfinir au niveau du playbook principal. Pour provisionner le container cjdns, il nous faut :

récupérer le container avec un docker pull

déclarer un service systemd pour démarrer le container comme un service système

activer le service qui vient d'être créé

trouver le chemin vers le fichier de configuration cjdns qui se trouve dans un volume docker séparé

et créer un lien symbolique de ce fichier vers /etc.

Nous voyons avec cela comment utiliser les variables. Pour utiliser une variable, il existe la syntaxe {{variable_name}}. Cette syntaxe correspond au langage de template Jinja2 et nécessite d'inclure les variables entre quotes pour rester valide YAML. Voir la documentation Ansible sur les variables.

Les modules peuvent définir des variables de leur propre chef, mais il est également possible d'enregistrer le résultat d'un module dans une variable avec la syntaxe register: variable_name. Pour visualiser les champs disponibles, il faut utiliser l'option -v sur la ligne de commande lorsqu'on exécute le playbook. Dans notre exemple, un champ file est disponible, et sera utilisé avec la syntaxe {{cjdroute_conf.file}}.

L'utilisation de ce rôle dans le playbook principal nécessite de définir une variable au moment de l'inclusion du rôle :

--- - hosts: perrin sudo: yes vars: name: perrin roles: - ipfs - role: cjdns-docker name: '{{name}}-cjdroute'

Si vous tentez d'exécuter ce role, il vous manquera les modules systemd-docker-service et docker-datadir. Leur conception n'implique rien de nouveau et voici leur code :

library/systemd-docker-service :

#!/bin/bash changed=false failed=false res_code=0 msg=Success exec 3>&1 >/dev/null 2>&1 trap 'failed=true res_code=1 msg="Failed at line $LINENO"' ERR name= cmdline= after= . "$1" changed=true cat <<EOF >/tmp/$$.1 [Unit] Description=Container $name Requires=docker.io.service After=docker.io.service $after [Service] Restart=always ExecStart=/usr/local/bin/docker-start-run $name $cmdline ExecStop=/usr/bin/docker stop -t 2 $name [Install] WantedBy=multi-user.target EOF :> /tmp/$$.2 chmod +x /tmp/$$.2 cat >>/tmp/$$.2 <<"EOF" #!/bin/bash name="$1" shift if ! id="$(/usr/bin/docker inspect --format="{{.ID}}" "$name-data" 2>/dev/null)"; then echo "Reusing $id" docker run --name "$name-data" --volumes-from "$name-data" --entrypoint /bin/true "$@" fi /usr/bin/docker rm "$name" 2>/dev/null set -x exec /usr/bin/docker run --name="$name" --volumes-from="$name-data" --rm --attach=stdout --attach=stderr "$@" if docker inspect --format="Reusing {{.ID}}" "$name" 2>/dev/null; then exec /usr/bin/docker start -a "$name" else exec /usr/bin/docker run --name="$name" --volumes-from="$name-data" --attach=stdout --attach=stderr "$@" fi EOF if ! cmp /tmp/$$.2 /usr/local/bin/docker-start-run; then mv /tmp/$$.2 /usr/local/bin/docker-start-run chmod +x /usr/local/bin/docker-start-run changed=true fi if ! cmp /tmp/$$.1 /etc/systemd/system/$name.service; then mv /tmp/$$.1 /etc/systemd/system/$name.service systemctl daemon-reload changed=true fi rm -f /tmp/$$.1 /tmp/$$.2 cat <<EOF >&3 { "failed": $failed, "changed": $changed, "msg": "$msg" } EOF exit $res_code

library/docker-datadir :

#!/bin/bash changed=false failed=false res_code=0 msg=Success

--- - shell: docker pull mildred/cjdns - systemd-docker-service: name='{{name}}' - service: name='{{name}}' enabled=yes state=restarted - docker-datadir: name='{{name}}' volume=/etc/cjdns file=/cjdroute.conf register: cjdroute_conf - file: src='{{cjdroute_conf.file}}' dest='/etc/docker-{{name}}.conf' state=link

exec 3>&1 >/dev/null 2>&1 trap 'failed=true res_code=1 msg="Failed at line $LINENO"' ERR name= image_name= volume= file= variable=file . "$1" : ${image_name:="$name-data"} changed=false res="$(docker inspect -f "{{(index .Volumes \"$volume\")}}" "$image_name")$file" cat <<EOF >&3 { "failed": $failed, "changed": $changed, "msg": "$msg", "$variable": "$res" } EOF exit $res_code

Un dernier rôle pour accéder par ssh à notre container

Nous voudrions pouvoir accéder au container docker en utilisant SSH avec un utilisateur particulier. Ceci peut se faire de manière générique pour tout container Docker, et c'est comme cela que nous l'implémenterons. Nous définirons un rôle pour ajouter un accès ssh, et l'utiliseront pour le docker cjdns.

Nous aurons besoin de nsenter, donc nous l'installons avec docker. Ensuite, nous créons un utilisateur avec l'UID 0 (afin qu'il ait les permissions d'exécuter nsenter), et nous spécifions une clef ssh de login, avec la commande nsenter qui nous permettra d'entrer dans le container :

roles/docker-ssh/vars/main.yml :

--- user: '{{name}}' shell: /bin/bash

roles/docker-ssh/tasks/main.yml :

--- - command: docker run --rm -v /usr/local/bin:/target jpetazzo/nsenter - user: name="{{user}}" uid=0 createhome=yes shell=/usr/sbin/nologin home='/home/{{user}}' - authorized_key: key="{{ssh_key}}" user='{{user}}' key_options='command="nsenter --target $(docker inspect --format {{ "{{.State.Pid}}" }} {{name}}) --mount --uts --ipc --net --pid {{shell}}"'

Pour utiliser ce nouveau rôle, nous allons le déclarer comme dépendance dans roles/cjdns-docker/meta/main.yml :

--- dependencies: - role: docker-ssh when: "'{{ssh_key}}' != ''"

Et notre playbook principal va être augmenté afin de définir la variable ssh_key pour le rôle docker-cjdns (qui sera ensuite héritée par le rôle docker-ssh instancié par dépendance) :

--- - hosts: perrin sudo: yes vars: admin_sshkey: ssh-rsa AAA...vgcv name: perrin roles: - ipfs - role: cjdns-docker name: '{{name}}-cjdroute' ssh_key: '{{admin_sshkey}}'

Nous avons vu dans cet article comment organiser notre code Ansible afin qu'il soit plus maintenable. Les rôles définissent des unités de code comme pourraient l'être des fonctions dans un langage plus classique. Il n'est pas possible d'invoquer un rôle directement au milieu d'une liste de tâches (dans ce cas, la directive include et le module include_vars existent), mais il est possible de définir des dépendances entre rôles. En guise d'exercice, il est laissé au soin du lecteur de décomposer le module systemd-docker-service en un rôle séparé.

[sogilisblog]

Ansible partie 2 : Créer un module simple pour installer des projets Go

La dernière fois, nous avions présenté le fonctionnement de base d'Ansible. Comment il était possible de définir une liste de tâches dans un playbook afin de les exécuter sur un serveur. Nous avions vu qu'il existait bon nombre de modules fournis de base permettant de réaliser des tâches très diverses. Mais que faire, si on veut faire quelque chose qui n'est pas prévu dans les modules prédéfinis ? Deux solutions :

A coup de tâches shell on exécute les commandes nécessaires, fastidieux, et peu maintenable.

On réalise un programme séparé (sous la forme d'un script shell dans notre exemple) qui va exécuter la tâche désignée et va s'interfacer en tant que module avec Ansible.

Un des grands avantages d'Ansible est de permettre de créer des modules dans n'importe quel langage de programmation. Il suffit que votre code soit exécutable, l'interface avec Ansible se fait via des paramètres en ligne de commande et la sortie texte du programme. Si le shell est plus adapté, on peut écrire du shell. Si on aime le Python, c'est possible. Le Ruby, bien sûr. Perl, Lua ou même en C, pourquoi pas.

Interface avec les modules Ansible

Un module Ansible s'utilise comme suit :

- module_name: parameters

module_name étant le nom du module, parameters étant une chaîne de caractères libre, généralement sous la forme clef=valeur, ceci n'étant pas obligatoire. Lorsqu'on utilise la forme clef=valeur, il est possible d'utiliser les modules avec une autre syntaxe un peu plus détaillée :

- module_name: key1: value1 key2: value2

Ceci est strictement équivalent à écrire :

- module_name: key1=value1 key2=value2

Lorsque ce module sera appelé, un programme au doux nom de module_name sera exécuté sur le serveur à déployer avec comme premier paramètre de ligne de commande un fichier contenant la ligne key1=value1 key2=value2. Le programme n'a qu'à lire ce fichier pour comprendre ce qu'il doit faire, et pour les scripts shell, c'est simple, parce que c'est la syntaxe shell de définition de variables. Il suffit donc de sourcer ce fichier.

Pour indiquer le résultat, il doit écrire sur la sortie standard ou d'erreur indifféremment un fichier JSON contenant des variables résultat, par exemple :

{ "failed": false, "changed": false }

Ceci indique à Ansible qu'il n'y a pas eu d'erreur (variable failed), que le système n'a pas été changé car il était déjà configuré (variable changed). Si la sortie du programme n'est pas valide JSON, le module sera considéré comme ayant échoué.

Un module pour installer des projets go

Pour les besoins de cet article, nous allons faire un module qui installe un programme écrit dans le langage Go. Une fois qu'on a go installé, il est très simple et rapide de compiler un programme Go. En effet, tout est généralement compilé statiquement sans dépendances externes, et l'outil go permet de récupérer récursivement toutes les sources nécessaires à un programme. Par exemple, pour installer le projet GitHub go-ipfs, il suffit d'exécuter les commandes suivantes :

go get github.com/jbenet/go-ipfs/cmd/ipfs go build github.com/jbenet/go-ipfs/cmd/ipfs go install github.com/jbenet/go-ipfs/cmd/ipfs

Ceci va télécharger les sources dans  $GOPATH/src, compiler dans $GOPATH/pkg et installer le programme ipfs dans $GOPATH/bin.

Installation dans /usr/local avec stow

Une autre astuce réside dans l'installation dans /usr/local en utilisant stow. C'est un programme qui permet de gérer le préfixe /usr/local et avec des liens symboliques, permet de savoir quel fichier appartient à quelle installation. Le principe est simple, au lieu d'installer un programme dans /usr/local/{bin,lib,share,...} directement, on l'installe dans /usr/local/stow/progname/{bin,lib,share,...}. Ensuite on invoque stow et on lui demande de créer des liens symboliques dans /usr/local/{bin,lib,share,...} pointant vers les fichiers équivalents dans /usr/local/stow/progname/{bin,lib,share,...}.

Par exemple, si on considère le langage Lua installé, nous trouvons les liens symboliques suivants :

lrwxrwxrwx 1 root staff 21 août 6 14:17 /usr/local/bin/lua -> ../stow/lua52/bin/lua lrwxrwxrwx 1 root staff 22 août 6 14:17 /usr/local/bin/luac -> ../stow/lua52/bin/luac lrwxrwxrwx 1 root staff 31 mai 13 2014 /usr/local/include/lauxlib.h -> ../stow/lua52/include/lauxlib.h lrwxrwxrwx 1 root staff 31 mai 13 2014 /usr/local/include/luaconf.h -> ../stow/lua52/include/luaconf.h lrwxrwxrwx 1 root staff 27 mai 13 2014 /usr/local/include/lua.h -> ../stow/lua52/include/lua.h lrwxrwxrwx 1 root staff 29 mai 13 2014 /usr/local/include/lua.hpp -> ../stow/lua52/include/lua.hpp lrwxrwxrwx 1 root staff 30 mai 13 2014 /usr/local/include/lualib.h -> ../stow/lua52/include/lualib.h lrwxrwxrwx 1 root staff 26 mai 13 2014 /usr/local/lib/liblua.a -> ../stow/lua52/lib/liblua.a -rw-r--r-- 1 root staff 2204 nov. 16 2011 /usr/local/share/man/man1/lua.1 -rw-r--r-- 1 root staff 3071 nov. 16 2011 /usr/local/share/man/man1/luac.1

Cela nécessite d'installer les programmes avec un préfixe particulier. Généralement cela se fait avec ./configure --prefix=/usr/local/stow/progname ou cmake -DCMAKE_INSTALL_PREFIX=/usr/local/stow/progname.

Un module pour installer un projet go avec stow

Une première version du module pourrait être la suivante :

#!/bin/sh exec 3>&1 >/dev/null 2>&1 . "$1" export GOPATH="/usr/local/src/$name" STOWDIR="/usr/local/stow/$name" rm -rf "$GOPATH/bin" "$STOWDIR/bin" mkdir -p "$STOWDIR/bin" "$GOPATH" ln -s "$STOWDIR/bin" "$GOPATH/bin" go get -u "$package" go build "$package" go install "$package" cd /usr/local/stow/ stow -R "$name" cat <<EOF >&3 { "failed": false, "changed": true } EOF exit 0

Ce module s'utilise ainsi :

- go-install: name=go-ipfs package=github.com/jbenet/go-ipfs/cmd/ipfs

Ce script va d'abord supprimer le dossier bin, créer un dossier /usr/local/stow/$name/bin et faire pointer /usr/local/src/$name/bin vers ce dernier dossier. Ainsi go install placera directement les fichiers dans /usr/local/stow/$name/bin.

La commande pour installer un paquet stow doit être exécutée dans /usr/local/stow. C'est stow -R $name (-R comme Restow).

Ne pas oublier la commande exec 3>&1 >/dev/null 2>&1 qui ferme la sortie standard et d'erreur afin d'éviter que les programmes ne polluent le résultat JSON, et 3>&1 (avant les autres) qui permet d'ouvrir le descripteur de fichier numéro 3 comme une nouvelle sortie standard. Le résultat JSON sera copié sur ce descripteur de fichier.

Un peu de robustesse

Afin de gérer les erreurs, le cas où les commandes exécutées retournent un code d'erreur différent de zéro, nous allons utiliser bash au lieu du vénérable shell POSIX sh et utiliser la commande trap. Nous allons aussi initialiser les variables dans le cas où notre environnement n'est pas propre, et donner une valeur par défaut à la variable $name :

#!/bin/bash failed=false res_code=0 msg=Success trap 'failed=true res_code=1 msg="Failed at line $LINENO"' ERR exec 3>&1 >/dev/null 2>&1 name= package= . "$1" : ${name:="$(basename $package)"} export GOPATH="/usr/local/src/$name" STOWDIR="/usr/local/stow/$name" rm -rf "$GOPATH/bin" "$STOWDIR/bin" mkdir -p "$STOWDIR/bin" "$GOPATH" ln -s "$STOWDIR/bin" "$GOPATH/bin" go get -u "$package" go build "$package" go install "$package" cd /usr/local/stow/ stow -R "$name" cat <<EOF >&3 { "failed": $failed, "changed": true, "msg": "$msg" } EOF exit $res_code

Utilisation du module

Pour utiliser le module, il doit être placé dans un dossier library/ au coté du playbook. Nous avons donc les fichiers suivants :

ipfs.yml hosts library/go-install

Notre playbook ipfs.yml pourrait être ainsi :

--- - hosts: perrin   sudo: yes   tasks: - go-install: name=go-ipfs package=github.com/jbenet/go-ipfs/cmd/ipfs

L'exécution donne ceci :

PLAY [perrin] ***************************************************************** GATHERING FACTS *************************************************************** ok: [perrin.mildred.fr] TASK: [go-install name=go-ipfs package=github.com/jbenet/go-ipfs/cmd/ipfs] **** changed: [perrin.mildred.fr] PLAY RECAP ******************************************************************** perrin.mildred.fr : ok=2 changed=1 unreachable=0 failed=0

Vous avez maintenant pu voir le fonctionnement des modules Ansible, je vous encourage à jouer avec. Si vous étiez à l'aise avec le shell, et redoutiez les outils de déploiement automatique — parce-qu'il faut l'avouer, le langage est parfois bien plus compliqué — vous êtes maintenant armé pour utiliser Ansible en toute simplicité. Dans un prochain article, nous verrons comment structurer des playbooks Ansible lorsque vous souhaitez mixer différentes tâches.

[sogilisblog]

Ansible partie 1 : La Base

La gestion de configuration

Ansible est un outil de déploiement automatique, il permet de facilement et surtout de manière reproductible, provisionner une machine. De manière concrète, cela permet :

d'installer des paquets

d'installer des fichiers de configuration

de configurer les utilisateurs systèmes

de configurer les services

de réaliser n'importe quelle tâche d'administration que l'on pourrait réaliser par ssh

La gestion automatique du déploiement est cruciale pour permettre d'avoir un serveur dans un état connu. La configuration manuelle d'un serveur est bien pour apprendre, mais au bout de quelques mois en production, nous oublions tous ce que nous y avons fait. Il est donc très important de consigner ces opérations quelque part.

Le premier réflexe serait de recopier toutes les commandes qu'on exécute déjà manuellement dans un gros script shell. Cela atteint très vite ses limites. Cela impose une rigueur à toute épreuve, et bien souvent nécessite de trouver du premier coup les bonnes commandes. Par exemple, si vous créez un utilisateur, mais que vous oubliez de spécifier le bon UID la première fois, il vous faudra le supprimer pour le recréer. Votre script shell va alors être truffé de conditions à n'en plus finir afin de lui permettre de fonctionner quel que soit l'état de base du système.

Les systèmes de déploiement comme chef, puppet, cfengine ou ansible dont nous parlons pourvoient déjà à ce genre de circonstances. Ils fournissent nombre de modules de base permettant la majorité des tâches d'administration du système, et fonctionnant quel que soit l'état de base dans lequel le système se trouve. Ils fournissent aussi en général un langage de haut niveau permettant de décrire de manière plus simple et moins sujette à erreur que des scripts shell.

Une partie intéressante de ces systèmes concerne également la gestion d'un parc de serveurs. Ils intègrent des outils afin de déployer de multiples serveurs sur la base d'une configuration similaire. Nous n'aborderons pas cette partie afin de se concentrer sur les fondamentaux de la configuration de systèmes.

Ansible, comment ça marche

Différents outils fonctionnent différemment. En ce qui concerne Ansible, ou plus particulièrement ansible-playbook, il s'agit d'un outil en ligne de commande qui va lire une configuration, se connecter à un serveur, et exécuter les commandes nécessaires sur ce serveur afin d'appliquer la configuration. Dans le jargon Ansible, cette configuration se nomme Playbook. Il s'agit de la liste des opérations à exécuter afin de configurer le système.

Notre premier hello world va utiliser deux fichiers. Vous avez d'abord besoin de décrire votre playbook. Ansible utilise une syntaxe YAML. Notre premier playbook va être :

--- - hosts: perrin   sudo: yes   tasks:     - shell: echo Hello World > /tmp/hello

Vous le constatez peut-être, mais ce playbook nous indique que nous voulons nous connecter au serveur appelé perrin, que nous utiliserons sudo afin de gagner les droits administrateur, et que notre seule tâche sera d'exécuter une commande shell permettant d'écrire Hello World dans /tmp/hello.

La seule chose que nous n'avons pas décrite, c'est comment accéder au serveur perrin. Pour cela, nous devons rédiger un fichier hosts comme celui-ci :

[perrin] perrin.mildred.fr ansible_ssh_user=admin

Il nous indique que dans le groupe perrin, nous avons un seul serveur dont le nom de domaine est perrin.mildred.fr et que le nom d'utilisateur pour s'y connecter en ssh est admin. Si nous voulions configurer plusieurs serveurs ensemble, il aurait été possible d'indiquer d'autres adresses sur les lignes suivantes.

Pour exécuter ce playbook sur ce serveur, la commande est la suivante :

ansible-playbook -i hosts hello/hello.yml

Dont le résultat nous donne :

_______________ < PLAY [perrin] > --------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || _________________ < GATHERING FACTS > ----------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || ok: [perrin.mildred.fr] ___________________________________________ < TASK: shell echo Hello World > /tmp/hello > ------------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || changed: [perrin.mildred.fr] ____________ < PLAY RECAP > ------------ \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || perrin.mildred.fr : ok=2 changed=1 unreachable=0 failed=0

Si comme moi, vous trouvez cette sortie peu lisible, je vous encourage a indiquer dans votre environnement (dans ~/.zshenv, ~/.bashrc ou ~/.profile) la variable d'environnement ANSIBLE_NOCOWS=1. N'oubliez pas de l'exporter avec le mot clef export. Vous devriez alors voir la sortie suivante :

PLAY [perrin] ***************************************************************** GATHERING FACTS *************************************************************** ok: [perrin.mildred.fr] TASK: [shell echo Hello World > /tmp/hello] *********************************** changed: [perrin.mildred.fr] PLAY RECAP ******************************************************************** perrin.mildred.fr : ok=2 changed=1 unreachable=0 failed=0

Nous pouvons visualiser les différentes tâches qui sont exécutées. Les tâches peuvent être dans plusieurs états, et cela est comptabilisé en fin d'exécution :

ok : le serveur était déjà configuré, rien à faire

changed : la configuration a été appliquée avec succès

failed : une erreur est survenue lors de l'exécution

unreachable : une précédente erreur a empêché l'exécution de cette tâche

Maintenant, vous êtes prêts à construire votre propre playbook. Nous n'avons pour le moment que survolé le module shell (qui nous permet d'exécuter des commandes shell), mais il existe plein d'autres modules. La documentation de ces modules est très bien faite, il faut s'y référer. Dans un prochain article, nous verrons comment construire facilement des modules personnalisés dans le cas où les modules proposés sont insuffisants.

[sogilisblog]

Découverte et amorçage de projet : qu'avons-nous appris de la planification par capacités ?

Dans ce dernier article, nous allons revoir les problèmes rencontrés avec les story maps et expliquer comment la planification par capacités apporte des réponses plus pertinentes dans notre contexte. Cette rétrospective nous montrera que l'essentiel n'est pas dans la méthode de Liz, mais bien dans sa façon d'approcher et de prioriser les problèmes - favoriser « les individus et leurs interactions plus que les processus et les outils ». Ceci nous mènera naturellement à une petite réflexion sur notre approche de l'agilité avec nos porteurs de projet.

Quelques leçons tirées de la cartographie par capacité

Les utilisateurs ne représentent que la partie visible des acteurs du projet

Dans le cadre d'une story map, l'accent est mis sur les activités et les cas d'utilisation du système. Cela peut conduire à se focaliser sur les utilisateurs principaux du système, au détriment d'autres acteurs moins en vue mais dont l'implication dans le projet peut être déterminante. Ainsi, au cours du développement d'une application web, nous avions fixé des pré-requis pour les navigateurs des clients. Mais nous nous sommes rendus compte bien tardivement que certains de nos collègues (impliqués indirectement dans le projet) n'avaient alors plus accès à l'application, car les pré-requis étaient trop hauts pour leur machine !

De plus, un focus trop rapide sur les utilisateurs entraîne facilement un focus sur les fonctionnalités, ce qui se fait au détriment de l'analyse des besoins et de la recherche de solutions. Le niveau de détails est trop bas pour s'imprégner des enjeux et des problématiques du projet. Cela peut même induire en erreur sur l'acteur et le besoin réel auquel répond la fonctionnalité.

La vision du projet, avec sa proposition de valeur mais aussi son impact sur les acteurs, est à cultiver dès le début : balayer tous les acteurs du projet, essayer de comprendre leurs besoins, leur attitude et leur impact sur le projet, si celui-ci sert leurs intérêts ou bien peut être un frein. Cette analyse a aussi pour but de ne pas se fixer d'oeillères sur ce qu'il faut réaliser : le but est de satisfaire au maximum les besoins de chaque acteur du projet. La solution ne passe pas forcément par une liste de fonctionnalités !

Le focus est sur la résolution de problèmes, pas sur les fonctionnalités

Le focus trop rapide sur les fonctionnalités peut aussi avoir des effets négatifs lors de la réalisation du projet.

Le besoin de la fonctionnalité est peu approfondie ; il n'en reste qu'une description superficielle, de laquelle il est difficile de revenir aux sources si on cherche une solution alternative.

La liste des fonctionnalités de la story map apparaît parfois comme un périmètre, à la manière d'un cahier des charges. Or beaucoup de choses peuvent encore changer en cours de projet.

La granularité des fonctionnalités peut être très hétérogène et leur description aussi : les « petites » fonctionnalités auront tendance à être plus détaillées que les grosses, car plus évidentes ; conjointement la complexité des grosses peut être masquée par le manque de détails dans leur description.

Des notions de valeur et de coût sont parfois utilisées pour aider à la priorisation des fonctionnalités. Ces notions posent des problèmes de définition (s'agit-il de la valeur en tant que nouveauté ou nécessité ? Quelle est l'échelle pour l'estimation du coût : story points, jour-hommes ?) Se focaliser sur ces estimations peut masquer des problèmes de dépendances : la fonctionnalité X n'est pas jugée intéressante car coûteuse, pourtant une sous-partie est nécessaire à une autre partie valorisable.

Bref, la story map peut donner une fausse impression de complétude, à la manière d'un cahier des charges, avec différents lots de fonctionnalités définis à l'avance. En cas de problème lors de la réalisation, le champ d'action pour rétablir le projet peut être limité car les acteurs auront du mal à sortir des rails de la story map.

Tout projet propose une vision différente par rapport à l'existant. Mais il existe plusieurs façons de réaliser cette vision. L'important est donc de ne pas avoir d'oeillères sur le chemin de la réalisation. Parler de capacités doit permettre de se concentrer sur le problème et le besoin à résoudre.

En prenant une approche centrée sur le problème, il y a moins de risque de passer du temps sur les détails d'une solution (la fonctionnalité) au détriment d'autres possibilités.

En exprimant les futures capacités du système, vous savez que vous devez chercher une solution pour satisfaire ces capacités. Les moyens de les satisfaire sont multiples et peuvent être remises en cause en cours de projet (nouvelles options, solutions alternatives et moins coûteuses). Le terme de capacité permet aussi plus facilement d'aborder les aspects non fonctionnels du système (robustesse, performance...).

En cas d'échec avec une solution, il est plus facile de repartir de la capacité que d'une fonctionnalité (quel est le problème, le besoin ? Comment y répondre ?).

La planification est basée sur le dérisquage et la valorisation du projet, pas sur la priorisation par estimation

La pratique courante issue des story maps et des méthodologies agiles est de prioriser les stories par rapport à leur valeur et leur coût estimé, pour les placer dans l'ordre dans le backlog. La notion de chemin critique, voire de MVP, est parfois abordée mais pas nécessairement approfondie. Le backlog ressemble alors à une liste de fonctionnalités à développer.

Le suivi se base sur la réalisation d'un plan (même s'il est léger) et il peut se créer un ressenti de retard ou de travail mal fait à cause des sacrifices faits par rapport au plan (fonctionnalité ou qualité).

La priorisation liée aux dépendances entre fonctionnalités est souvent masquée dans cette approche ; cela peut rendre la repriorisation complexe.

Si une fonctionnalité se révèle mal estimée en cours de sprint, des décalages liés à la résolution des problèmes se créent dans le suivi de charge, ce qui peut être perturbant pour une équipe mal rôdée ; l'équipe pense prendre du retard, qui ne peut être rattrapé sauf à changer le périmètre.

Même tard en fin de projet, on peut tomber sur une exigence complexe, mal estimée, qui rend difficile la vision sur la fin du projet.

Plus on est ignorant sur un aspect du projet, moins on sera pertinent pour son estimation, plus on prend des risques à s'engager. Or les plans type story map tendent malgré tout à un engagement, même peu formalisé.

En se focalisant sur les risques d'échec ainsi que sur les points différenciants, l'accent est mis sur l'essentiel : trouver la prochaine étape la plus sûre et la plus rapide pour démontrer la valeur du projet, avant de passer à la suivante. L'approche vise la réalisation de la vision, la résolution des problèmes rencontrés, plutôt que la coche de fonctionnalités dans une liste.

Traiter l'estimation comme une projection, pas un engagement

Bien que l'on sorte du cadre strict de la planification, l'estimation du coût d'un projet est la suite logique pour un porteur. Là encore, Dan North en a très bien décrit les enjeux et les écueils dans The Perils of Estimation et même proposé son idée dans Blink Estimation.

Sans rentrer dans le détail de ce débat (voir tout ce qui concerne le No Estimates), la méthode de Liz apporte son petit grain de sel aux estimations. En effet, plus vous estimez que le niveau de risque est fort, plus il y a d'inconnus sur les problèmes que vous allez rencontrer, et plus votre estimation sera incertaine. Jusqu'au point où une estimation n'est plus pertinente et où vous devez commencer par une approche exploratoire, moins risquée et moins coûteuse.

Plus simplement, la question de l'estimation peut être traitée par l'équipe comme une projection dans l'avenir. Quelle horizon se donne-t-elle pour trouver une solution à ce problème ? Et quelle confiance a-t-elle dans cette horizon ? Si l'équipe n'est pas confiante, comment réduire le risque ? Si besoin, l'équipe peut renforcer son opinion en utilisant le poker planning, mais l'estimation ne doit pas se transformer en chiffrage de fonctionnalités à la carte.

Et si le porteur de projet a déjà un cahier des charges, un backlog, des idées toutes prêtes…

Stop ! La démarche ci-dessus doit normalement pousser tout le monde à remettre en cause des fonctionnalités prématurées, à proposer d'autres solutions. Si le porteur insiste pour inclure une fonctionnalité dans votre cartographie, comment pouvez-vous la réexprimer comme une capacité, en gardant la fonctionnalité comme un exemple de solution concrète pour cette capacité ? Comme proposé par Liz, demandez au porteur pourquoi il veut cette fonctionnalité et jusqu'à remonter aux besoins pour pouvoir exprimer la capacité.

Obsolète, la story map ?

Comme noté dans le premier article, la story map pose problème dans notre contexte de découverte de projet, où le domaine est souvent nouveau pour l'équipe et les pratiques agiles inconnues des porteurs de projet. La planification par capacités est plus abordable et nous permet de découvrir plus rapidement les fondamentaux d'un projet naissant, mais aussi d'organiser les premières itérations, produire des prototypes de démonstration, prévoir les prochaines étapes - et pourquoi pas servir de base à une story map qui détaillera plus les fonctionnalités.

Quand l'équipe a acquis plus de maturité sur le domaine, ses enjeux et ses problèmes, il peut être intéressant d'engager un processus orienté story map. Celle-ci permet de récapituler la vision de ce qu'on veut réaliser, la réordonner, préparer les détails des prochaines itérations, quand la vision du projet s'est stabilisée. Elle permettra alors un suivi des étapes du projet à la vue de tous, lot par lot.

Peut-on complètement se passer de la story map ? Je crois que oui. Comme noté par Dan North, des équipes très efficaces se sont construites en dehors de la culture agile classique, simplement en appliquant du bon sens dans leurs pratiques. La planification par capacités n'est qu'une des pratiques supportant ce type d'approche.

Changer notre approche de l'agilité (encore et toujours)

Avoir persisté si longtemps dans une approche inadaptée amène une remise en question. Au-delà de l'utilité de la planification par capacités, cette expérience nous a forcé à oublier certaines méthodes et pratiques de l'agilité pour revenir aux fondamentaux.

Sortir des rails des process agiles

Tout le monde a vécu un jour ou l'autre cette expérience : copier une approche qui a « déjà marché » ailleurs ; et quand ça ne marche pas, recommencer en expliquant que les règles n'ont pas été bien suivies. Certaines méthodes agiles ont un côté très cadré, cérémonieux qui encouragent ce comportement. Dans le pire des cas, on arrive à l'agilité Cargo Cult, où l'équipe se déclare agile parce qu'elle applique toutes les règles, mais sans en tirer les bénéfices car elle n'a pas su les adapter à son contexte.

Ce qui est rarement dit sur les méthodes agiles, c'est qu'elles demandent souvent une bonne maturité sur le domaine du projet pour être 100% effective. Rien n'est plus plaisant que de travailler sur un projet complexe où chaque itération réussit son objectif, car l'équipe maîtrise les enjeux, réagit immédiatement aux problèmes rencontrés, communique efficacement avec les autres acteurs du projet.

Mais quand nous avons affaire à des domaines inconnus, ces éléments sont loins d'être acquis : l'équipe cherche le bon niveau de communication, les zones d'ombre sont nombreuses, les enjeux encore mal identifiés. Il est tentant, et rassurant, pour l'équipe comme pour le porteur de se retrancher derrière un process, un contrat, un cahier des charges…

Par ailleurs, les outils agiles comme la story map semblent souvent simples, voire triviaux en apparence, mais demandent une bonne expérience pour être bien menés. Amener des nouveaux venus à utiliser ce type d'outil dès les premiers contacts rend les choses complexes !

C'est pourquoi choisir une approche moins structurée que la story map, comme la planification par capacité, est intéressant. Le niveau d'entrée est faible, car n'imposant pas différents concepts hiérarchisés (activité, cas d'utilisation, fonctionnalité) : la capacité résume ces concepts tout étant suffisamment souple pour que chacun se l'approprie. A ce stade, l'essentiel pour nous est d'échanger sur le projet. En enlevant des barrières de communication, il est plus facile pour l'équipe de faire valoir son point de vue, sa force de proposition, et de ne pas apparaître comme une simple exécutante.

La culture de l'accompagnement

Mais dans l'approche de Liz Keogh, l'aspect le plus intéressant et révélateur est certainement la prise en considération de sa propre ignorance et des risques associés. D'abord parce qu'elle met l'accent sur le non-dit des projets au forfait, typique des SSII : sur quelles bases et quelles estimations la proposition de forfait a-t-elle été faite ? Quels risques ont été pris en compte ? Comment l'équipe va-t-elle gérer et communiquer sur ces risques ? En règle générale, les risques ne sont considérés que comme un facteur multiplicateur dans l'estimation (car le temps est court pour faire une proposition) et les risques seront gérés comme ils arrivent, et parfois dans l'urgence de la crise.

Le risque, l'inconnu est un paramètre essentiel de n'importe quel projet, en particulier pour une start-up. C'est pourquoi nous voulons le mettre au centre de notre approche. Pour un porteur de projet, notre première proposition est donc un accompagnement. La réponse que nous apportons n'est pas forcément une estimation de son projet mais plutôt une projection : que pouvons-nous faire, quelle est la prochaine étape ? Notre métier n'est pas que de développer des fonctionnalités, mais d'accompagner les porteurs à travers des étapes en proposant des solutions à moindre risque.

Simon Denier simondenier sdenier +SimonDenier

[sogilisblog]

Découverte et amorçage de projet : planifier des capacités et des risques

Simon Denier simondenier sdenier +SimonDenier

[sogilisblog]

Découverte et amorçage de projet : le problème avec les story maps

Tout projet commence par une phase d'élaboration et de maturation des idées, que ce soit sur la problématique et les objectifs, le financement, la commercialisation, et bien sûr la technique. L'équipe technique se retrouve alors confrontée à la question de la réalisation : que doit-on faire, quels sont les délais, combien ça va coûter ? Un des outils mis en avant pour planifier un projet en mode agile est la story map. Or notre expérience avec cet outil s'est révélée très hétérogène voire paradoxale. En effet, elle n'est pas forcément pertinente pour répondre aux questions essentielles en tout début de projet : combien investir et quelle est la prochaine étape ? Ce premier article fouille quelques-uns des défauts constatés avec l'approche story map, avant d'aborder la prochaine fois une autre approche basée sur les capacités et les risques.

Petit rappel : ce qu'est une story map

Une story map est un atelier rassemblant différents acteurs d'un projet (Product Owner, utilisateurs, développeurs) en vue de planifier les futures fonctionnalités du système. Elle se déroule suivant les étapes ci-dessous :

décrire la vision du projet

identifier les acteurs en lien avec le projet (parties prenantes, utilisateurs, bénéficiaires…) et leurs besoins

lister les activités de chaque acteur

pour chaque activité, identifier des cas d'utilisation

classer les cas d'utilisation par lots, suivant des critères de nécessité et de valeur

La story map est un processus itératif : les activités et cas d'utilisation sont raffinés au fur et à mesure de l'atelier. A l'issue du processus, les cas d'utilisation seront déclinés en stories pour décrire les fonctionnalités et rentreront dans le backlog suivant la priorité décidée par les lots.

Si vous ignorez tout des story maps et que vous voulez lire la suite de cet article, je vous recommande « The new user story backlog is a map ». Vous en saurez plus sur l'origine de l'idée, les étapes à suivre, et l'usage que l'on peut en faire en gestion de projet agile.

La story map comme outil de découverte d'un projet ?

Les porteurs de projet qui viennent nous voir sont à la recherche d'expertise sur la partie technique et fonctionnelle de leur projet aussi bien que sur la planification pour mener à bien un produit minimum viable.

Ces porteurs arrivent avec des maturités différentes vis-à-vis de leur projet. Certains travaillent dans le domaine depuis des années et se lancent sur une idée mûrement réfléchie. D'autres s'engagent dans l'aventure et découvrent la problématique en même temps qu'ils proposent des solutions. Lors des premiers rendez-vous, nous voyons arriver des porteurs avec des cahiers des charges denses et illisibles, tandis que d'autres ont toutes leurs idées en tête et s'adaptent très vite à nos méthodes de travail.

Nous avions donc besoin d'une méthode pour nous aider à découvrir rapidement un projet et à encadrer les clients lors des phases de découverte. La story map semblait un outil intéressant pour cela. De plus utiliser cet outil nous donnaient une chance d'être actif dans la recherche d'informations, a contrario de la lecture d'un cahier des charges, plus passive et fastidieuse. Cela nous permettait de dénicher plus facilement des points obscurs - interpeller le porteur de projets et le faire sortir de ses habitudes - et d'exposer de futurs clients à nos méthodes :

atelier favorisant la discussion entre participants

post-its pour garder les idées concises et essentielles

focus sur les utilisateurs

priorisation et construction des lots dynamiques, en groupe…

vision complète et amélioration incrémentale pour favoriser le raffinement des points clés

Sur le papier, la story map avait donc tout pour plaire. Mais notre expérience avec les story maps en découverte de projet s'est révélée très hétérogène voire paradoxale. Parfois cela marchait bien, révélant les différents aspects du projet. Régulièrement, le résultat ne semblait pas à la hauteur des efforts fournis lors de la session. Dans au moins deux cas, la story map s'est révélée complètement inadaptée. Pourtant, c'est une étape structurante dans la vie d'un projet, d'autant plus qu'il s'agit souvent du premier contact entre l'équipe technique et le porteur de projet. Il est donc frustrant de commencer par une session de travail qui ne marche pas bien.

Même joueur essaie encore

En bons agilistes, nous avons essayé d'adapter l'outil et ses règles pour rendre les story maps plus faciles à gérer, plus pertinentes pour tout le monde : essayer d'extraire les besoins de chaque acteur, garder un haut niveau d'abstraction pour les activités, recadrer dès qu'on s'attarde trop sur le détail, faire exprimer aux participants leur flot de travail…

Malgré ces adaptations au fil de l'eau, les story maps se finissaient souvent pour nous sur les constats suivant :

c'est usant, voire stressant, et malgré nos efforts nous n'étions pas sûr d'avoir une vision correcte du projet !

d'une story map à l'autre, le niveau d'expression et d'abstraction était très différent et ne permettait pas la même exploitation des résultats : tel aspect évoqué par les participants n'apparaissait pas clairement dans la story map, tel autre manquait de précision et entraînait des incompréhensions et des décisions mal ajustées…

Les problèmes des story maps en découverte de projet

Pourquoi donc cela ne marche pas toujours comme souhaité ? Plusieurs problèmes récurrents peuvent apparaître.

Les concepts : activité, cas d'utilisation, fonctionnalité ?

Il est parfois difficile d'expliquer la nuance entre activité, cas d'utilisation ou fonctionnalité, face à des clients qui découvrent la méthode. Ces concepts doivent de plus être calibrés en fonction de la taille du projet. Souvent, une activité est d'abord exprimée comme une fonctionnalité. Il faut ensuite la reformuler de façon plus abstraite en cours de session, quand la confusion s'installe entre activité et fonctionnalité.

Granularité hétérogène des activités et cas d'utilisation

La granularité des activités et cas d'utilisation est très variable au sein d'une story map. A la manière de la loi de futilité de Parkinson, des aspects « simples » de la story map se retrouvent au même niveau d'expression que des aspects complexes, entretenant une certaine confusion sur les points durs du projet. En essayant de balayer toutes les activités du projet, les aspects les plus difficiles ne sont pas nécessairement les plus approfondis.

Granularité hétérogène entre différentes story maps

La granularité entre différentes story maps est aussi très hétérogène. Cela n'est pas surprenant. Mais ce qui est définit comme une activité pour un « petit » projet, définie par plusieurs cas d'utilisations, peut s'exprimer comme un seul cas d'utilisation dans un projet plus important, car il est impossible de rentrer dans les détails. Il y a donc nécessairement une perte d'information entre les deux, ce qui est perturbant quand on doit juger de la complexité d'une activité.

L'effet rush

Afin de profiter au maximum de la présence des participants, nous faisions des sessions intenses d'une demi-journée à une journée complète, parfois plus, ce qui entraînait souvent des « rushs » en fin de session pour faire le tour des activités dans le temps imparti, au détriment de la qualité de la discussion.

C'est difficile sur de gros projets

Clairement, l'atelier story map n'a jamais marché quand nous avons essayé sur de gros projets. Cela demande encore plus de maturité, de temps de découverte du domaine. Le focus sur les activités et les cas d'utilisation n'est pas au bon niveau pour découvrir ces projets.

Le focus « utilisateur » n'est pas forcément adapté

Même si la story map est censée aborder tous les acteurs concernés par le projet, le focus sur les activités et les interactions avec le système conduit naturellement à mettre l'accent sur les seuls utilisateurs. Suivant le stade du projet, ce n'est pas forcément pertinent : il peut être tout aussi important de se concentrer sur d'autres parties prenantes, non utilisatrices, qui seraient impactées par le projet et pourraient y mettre un terme.

La story map rend difficilement compte des aspects techniques

Le format story map permet difficilement de mettre l'accent sur des problématiques techniques, non-fonctionnelles. Or, celles-ci peuvent être structurantes pour un projet, en particulier en phase de démarrage et de démonstration technologique.

La story map ne rend pas compte des points à explorer

Les doutes ou besoins exprimés par le porteur ou par l'équipe n'apparaissent pas nécessairement. Les zones d'ombres n'étant pas clairement identifiées, certaines décisions semblent figées dans le marbre. Entre autres, les problèmes d'ordre technique sont souvent évacués au motif que le sujet est prématuré et qu'il faut se concentrer sur le fonctionnel. C'est bien sûr souvent vrai, mais cela n'empêche pas de prendre en compte un problème technique fondamental dans la découverte d'un projet.

La story map fige le périmètre des fonctionnalités

Malgré toutes les précautions et les règles de bonne conduite, le résultat le plus tangible d'une story map est la liste des cas d'utilisation, qui se transforme vite en liste des fonctionnalités attendues, ce qui a tendance à figer le périmètre trop tôt.

Le vrai problème avec les story maps : les attentes contrariées

Malgré ces inconvénients, nous croyons quand même dans la valeur de la story map à ce stade car elle permet avant tout la discussion et l'échange. Mais alors, pourquoi la story map peut-elle se montrer vraiment inadaptée dans cette phase du projet ? Face au même résultat, les deux côtés peuvent avoir des questions et des attentes très différentes, par exemple :

Equipe technique

Nous avons une première vue de fonctionnalités minimales, nous pouvons commencer au plus vite pour fournir un produit minimum viable.

Quand voulez-vous commencer ?

Porteur de projet

Est-ce que la story map correspond à la liste des fonctionnalités ? Qu'est-ce qui va rentrer dans le périmètre final ?

Combien ça va coûter ?

Bizarrement, cette dernière question provoquait toujours chez nous une sensation de malaise. Une story map ne permet pas de fournir une meilleure estimation qu'une autre méthode (tout au plus favorise-t-elle la comparaison pour un chiffrage relatif 1). Il nous manquait toujours des informations cruciales au moment du chiffrage pour être serein. Au final, nous nous sentions piégés dans les vieilles habitudes de chiffrage du cahier des charges. De plus, la story map ne nous offrait pas toujours une vision claire sur la prochaine étape : peut-on commencer tout de suite ? Y a-t-il d'autres étapes non techniques à valider d'abord ?

La story map est-elle utile ?

On dit « si tu as un marteau dans la tête, alors toutes les vis ressemblent à un clou ». Quand on a un bel outil en main, il est facile de regarder tous les problèmes par son prisme, même quand il est inadapté à la situation. C'est ce qui se passe avec la story map pour la découverte d'un projet. Elle ne permet bien souvent pas de répondre aux questions essentielles du porteur de projet en phase de découverte : est-ce que mon projet marche dans la réalité ? Est-ce qu'on a identifié les problèmes clés ? Combien investir et comment procéder pour tester au mieux les idées ?

Bien sûr, il ne s'agit pas de remettre en cause la story map comme outil de planification de projet, quand celui-ci devient plus mature, que le périmètre des fonctionnalités se dessine et que les priorités sont identifiées. Simplement, elle ne peut pas venir trop tôt dans la découverte d'un projet, car elle risque de figer des décisions sur les fonctionnalités à un moment où celles-ci sont encore méconnues. Nous verrons dans le prochain article une approche qui se focalise sur les capacités et les risques du projet, afin de trouver une organisation plus pragmatique du développement.

Simon Denier simondenier sdenier +SimonDenier

A propos des estimations, comment les faire, les exploiter intelligemment et les éviter quand ce n'est pas utile, je recommande Dan North (The Perils of Estimation, Blink Estimation) et aussi tout ce qui touche au mouvement NoEstimates. Mais c'est un autre sujet. ↩︎

[sogilisblog]

Une vision du business, ou comment éviter de se prendre le mur !

Money, Money, Money ------------------- Comme le disait Clint Eastwood : _« Tu vois, le monde se divise en deux catégories : ceux qui ont un pistolet chargé et ceux qui creusent. Toi, tu creuses. »_ Pour les start-up, c’est globalement du pareil au même et elles se définissent facilement de la manière suivante. On pourrait dire : _« Tu vois, les start-up se divisent en deux catégories : celles qui ont de l’argent et celles qui creusent. Toi, tu creuses. »_

Photo : Generation Grundeinkommen

Aujourd’hui, quand je rencontre des porteurs de projets, ce qu’ils souhaitent en premier lieu, c’est de l’argent, beaucoup d’argent : celui de l’état, des investisseurs, des Business Angels, et aujourd’hui celui des Kickstarter et consors. Tout cela avant même d’avoir vendu le moindre produit ou le moindre service, et surtout d’avoir rencontré un futur client, s’être confronté au marché. Vous l’aurez compris : sans argent pas de projet, sans projet pas d’argent, tout cela se mord facilement la queue au risque de voir son business plan « émasculé » avant même d’avoir engrangé le premier €uro ! Souvent, demander de l’argent, des aides financières trop tôt n’est qu’un moyen pour repousser le moment où l’on se prend le mur…

Conseil n° 1 : garder à l’esprit qu’il est important d’aller rapidement vers les premiers revenus, en économisant vos ressources financières et humaines, sans nécessairement développer l’ensemble de votre produit. L’argent est important, l’accès à votre marché davantage.

Business plan sur la comète

Ne soyons pas dupe : oui, il y a toujours besoin d’argent pour accroître son business, mais il existe des techniques pour optimiser le remplissage de la caisse, sans avoir à développer l’ensemble de son produit ou de son offre.

Photo : FryskLab

Aujourd’hui, on remplace aisément le « business plan sur la comète » réalisé avec un joli tableur, par une feuille A4 ou A3 si on a de l’inspiration, en mode paysage, avec un certain nombre de cases à remplir et des post-it, que l’on appelle canvas. A-t-on réellement changé les choses ? Est-ce que les investisseurs vont se pencher sur votre cas avec ce changement de formalisme ? Est-ce que la nébuleuse Kickstarter va se jeter sur votre produit grâce à ce canvas ? Beaucoup de start-up y croient dur comme fer, certains organismes publics en sont même convaincus, c’est pour dire la révolution. Mais l’investisseur, le banquier, etc., sont-ils davantage rassurés sur la pertinence de votre offre, la validité de votre business et la rentabilité très très rapide de votre petite entreprise ? Inutile de vous donner la réponse…

Le premier jet de votre canvas ne vous servira pas plus que votre tableur si vous en restez là. Les canvas sont faits pour être vivants et pour évoluer. Je ne décrirai pas ici leur fonctionnement, en cherchant la définition « canvas business model » sur Google, vous devriez trouver votre bonheur dans les 13 millions de liens fournis. Les canvas permettent un formalisme très intéressant, permettant de catégoriser, classifier, voir plus clair. Ils peuvent être vus comme votre partition, que vous créez, adaptez, sur laquelle vous allez rajouter des arrangements…

L’élaboration de ces canvas doit impérativement se réaliser en mode itératif, avec un processus constructif et évolutif. C’est ainsi que vous allez entrer dans un système bannissant les plans irréalistes, les idées préconçues, et ainsi faire évoluer votre partition.

Conseil n°2 : Faites vous aider. Disposer d’un regard externe peut vous faire gagner du temps, encore faut-il qu’il soit critique et puisse vous faire pivoter si besoin. Si possible, excluez les « bons amis » et les « meilleurs potes de 20 ans » qui auront globalement des avis tranchés, dans un sens comme dans l’autre.

Catégoriser votre business, vous dormirez mieux

Beaucoup de porteurs de projets sont convaincus de l’Utilité de leur produit (avec un grand U). Ils vont alors axer leur stratégie marché en fonction d’utilisations et d’usages qui vont changer le monde, certes. Cette stratégie est tout à leur honneur : « change the world », aider les gens, leur simplifier la tâche, etc. Il existe beaucoup de raisons de penser que ce que l’on crée va aider à améliorer le quotidien de chacun de nous, sauf que…

Sauf que s’enfermer dans la stratégie de l’utile peut abattre des portes qui vous tendent les bras. Pour illustration, allez faire un tour sur Kickstarter ou sur les réseaux sociaux, vous y trouverez alors de nombreux projets qui au départ pouvaient avoir un côté utile, et qui se sont transformés en produits gadgets, non plus destinés au commun des mortels en quête de praticité, mais destinés aux « early adopters ».

Photo : Athenamama

Cette stratégie est tout aussi excellente que la première, les « early adopters » sont nombreux, prêts à mettre des centaines, voire des milliers d’€uros dans le dernier gadget à la mode, quitte à attendre 12 mois la production du soit disant « dernier produit branché en avance sur les autres mais que je n’aurai que dans 12 mois ». Oui, cette clientèle existe, et il ne faut surtout pas la négliger.

Autre catégorie qui heureusement existe, l’utile qui est cool – le cool qui est utile fonctionne aussi –, fun, et en plus utile, et cool, etc. Une sorte de cerise sur le gâteau, le Saint Graal du startuper, un savant dosage de « c’est le truc qui manquait à ma vie » et de « c’est trop fun ce truc, je vais pouvoir briller en soirée maintenant, enfin, dans 12 mois… ».

Conseil n°3 : Ayez une stratégie, mais n’hésitez pas à la remettre en cause. N’éliminez pas le côté fun de ce que vous développez, n’omettez pas le côté utile de votre produit.

Un syndrome : la peur du client

Le client est une sorte de lame en céramique qui serait capable d’anéantir votre business en moins de deux. En plus, au départ il ne sait pas ce qu’il veut : autant lui imposer.

Il est indécis, c’est qu’il n’est pas encore au courant que vous détenez la dernière meilleure idée du siècle.

Il ne veut pas de votre produit, c’est qu’il n’a rien compris à ce que vous lui proposez.

Il doute de l’utilité de votre produit, c’est un « français », il doute de tout.

Il n’est pas là, au bon moment, au bon endroit, quel « con » ce client. Le pire, c’est qu’il critique votre produit ! Insupportable, inadmissible.

Sauf que : le client a toujours raison, ou presque, d’autant plus que c’est lui qui va acheter votre produit. La principale conséquence des idées préconçues ci-dessus est que vous n’allez pas le rencontrer. Vous allez penser à sa place, c’est quand même plus simple, plus confortable : il fait peur.

Conseil n°4 : n’oubliez pas que vous n’êtes pas forcément le client de ce que vous produisez. Se confronter au marché n’est pas une chose simple. Il existe pourtant des techniques éprouvées à mettre en oeuvre pour casser cette barrière. Elles doivent être réalisées au cas par cas en fonction des hypothèses marché que l’on peut émettre.

Des conseils pour mon business, non, pas pour moi

Se faire accompagner a un coût, je ne le cache pas, et beaucoup de porteurs de projets économisent de manière naturelle sur ce poste de dépenses. J’ai forcément un avis biaisé, j’en conviens. Cet accompagnement a d’autant plus un coût que la plupart des startupers sont persuadés d’avoir en leurs mains l’idée du siècle, qu’ils vont mener à terme sans embûche. Au passage, ils en profiteront pour tenir secret leur bébé, jusqu’à terme – si terme il y a –, en évitant le syndrome de la « fausse couche ».

Dans ce contexte, ils vont tout faire pour économiser sur des postes qu’ils vont juger opportuns. Rien de plus normal : chacun connaît ses postes de dépenses et les coupes franches vont bon train, ces dernières étant logiquement arbitrées par le bon sens, les impressions et le feeling – au choix –, quitte à repousser le moment où l’on va se faire accompagner.

Photo : Thomas Shawk

Aujourd’hui, beaucoup de structures proposent des accompagnements business gratuits, annuels, sous forme de promotions. Le côté buzz est indéniable et génère un aspect relativement positif pour l’écosystème des start-up et projets innovants qui fleurissent de-ci de-là. En disant cela, c’est certain, je ne vais pas me faire que des copains dans la cours de récré, mais…

Mais sortons de la bulle et revenons sur terre. Rien n’est gratuit, nous développons tous du business et de la valeur ajoutée. J’ai un regard assez critique sur cette forme d’accompagnement dit « gratuit ». Vous faire croire que votre business entre dans un système qui est de l’ordre du caritatif n’est que pure illusion. Petit exercice : essayez de saupoudrer du sucre glace sur un gâteau, ce n’est pas pour autant qu’il aura un goût sucré.

Depuis de nombreuses années, nous accompagnons des entreprises sur des problématiques techniques de pointe. Notre manière de travailler, en suivant notamment les principes de l’Agilité, nous a amené à collaborer avec des jeunes pousses sur le business qu’elles mettaient en oeuvre.

Fort de nombreuses expertises techniques et d’immersions de nos experts dans le business des entreprises qui nous ont fait confiance, nous avons développé une nouvelle cellule dédiée à l’accélération de start-up. Cette dernière met à la disposition des porteurs de projets un accompagnement aux composantes essentielles : tout d’abord de type business, mais aussi technique, couplé à une aide à la recherche de financements publics.

La partie business est la pierre angulaire de notre accompagnement, elle va déterminer l’activation d’une potentielle aide technique, mais va aussi permettre aux porteurs de projets de profiter de notre expertise concernant la recherche de financements.

Conseil n°5 : Se faire accompagner n’est pas un signe de faiblesse. Se faire réellement accompagner – cf. l’analogie au sucre glace – ne doit pas être considéré comme un luxe, destiné à ceux auront trouvé la solution de qui de l’oeuf ou de la poule est arrivé le premier. Votre temps est précieux, et malheureusement votre temps c’est de l’argent : Money, Money, Money… CQFD.

A propos de l’auteur

Xavier Spengler développe l’activité lyonnaise de Sogilis et fait partie de la cellule accompagnement business auprès des start-up. Il accompagne les porteurs de projets (numérique, électronique, web…), leur permettant d’accéder le plus rapidement possible aux premiers revenus et rendre leurs projets pérennes.

[sogilisblog]

Un témoignage de notre équipe pour clôturer l’année

Quelques nouvelles : notre entreprise grenobloise s’agrandit. Nous sommes aujourd’hui une vingtaine et nous nous installerons bientôt dans de nouveaux locaux à Europole. Depuis octobre, nous étendons notre présence en Rhône-Alpes : nous accélérons les start-up à Lyon.

Deux membres de la Sogiteam ont récemment été interviewés sur leur travail au quotidien. On dit souvent que Sogilis est une entreprise libérée. Mais concrètement, qu'est-ce que cela signifie ?

Sur le blog de l'entreprise collaborative tenu par Aurélie Duthoit, nos deux collègues s'expriment. Pour Myriam, travailler dans une entreprise libérée, « c'est moins de justifications et plus d'actions ». Ce que Victor aime tout particulièrement, c'est de ne pas avoir peur de se tromper. Du recrutement à la rentabilité, voici leur retour d'expérience :

Témoignages de collaborateurs de Sogilis, une entreprise libérée

Peut-être cela donnera-t-il des idées à certains pour la nouvelle année…

Etre une entreprise libérée, c'est pas si facile... Mais on ne la laissera pas tomber !

[sogilisblog]

Joyeux Noël !

Noël au bureau, c'est comment ?

C'est comme ça :

Comme ça aussi :

Et ça peut même ressembler à ça... L'hôte Mouss' sait nous recevoir et régaler la compagnie !

De très bonne humeur après ce festin, c'est l'heure de... ah oui :

L'équipe de Sogilis vous souhaite un Joyeux Noël !