Maîtrisez vos environnements de développement via docker-compose

1. Pourquoi un environnement reproductible est-il important ?

Avez vous déjà utilisé un gestionnaire de dépendance ? De Maven à pip en passant par npm ou nugget, tous les langages ont aujourd’hui leurs gestionnaires. Si vous cherchez à comprendre pourquoi, je vous invite à essayer de développer sans.

Une des principales fonctionnalités de ces gestionnaires est de pouvoir rassembler l’ensemble des informations nécessaires au téléchargement des dépendances dans un fichier externe, tel que le package.json de NPM.

Mais s’il est aujourd’hui naturel, grâce à ces gestionnaires, de ne plus se soucier de noter les numéros de versions des dépendances utilisés ou du téléchargements de ces dépendances, peut on en dire autant concernant l’environnement de développement en lui-même ?

N’avez-vous jamais eu de problèmes quand vos collègues n’ont pas la même version de java/python/JS/etc que vous ? Ou un OS différent, et donc une librairie manquante à la compilation du projet ?

Vous semble-t-il simple aujourd’hui de gérer de multiples versions de votre base de données, une pour chaque projet, à coté de vos nombreuses stacks technologique ?

Ces problèmes en plus de vous faire perdre du temps, génère de la frustration. Et s’il était possible de reproduire un environnement aussi facilement que d’installer les dépendances d’un projet ? Et si l’OS n’importait plus ? Me croiriez vous ?

2. Comment y parvenir ?

Quels sont donc les caractéristiques que nous souhaiterions réunir dans cet environnement ?

  1. Un fichier ou un ensemble de fichier doivent le décrire complètement et retenir les versions utilisées
  2. Ce ou ces fichiers doivent avoir un historique afin de pouvoir retracer l’évolution de l’environnement
  3. Il doit être simple d’installer l’ensemble de l’environnement
  4. Il doit être simple de modifier l’environnement et de rapidement transmettre cette modification à toute l’équipe

Nous avons donc 4 caractéristiques qui nous permettrait de simplifier notre vie de développeur.

Historiquement, un des meilleurs moyen de pouvoir fournir un environnement complet, et reproductible, se trouvait dans la virtualisation. Créer une machine virtuelle à partir d’un modèle et fournir ensuite ce modèle à toute l’équipe était en effet un bon moyen d’obtenir un environnement reproductible. D’ailleurs, ce n’est pas pour rien que des outils comment Vagrant sont devenus si populaire. Vagrant met d’ailleurs en avant une autre caractéristique importante, le fait de pouvoir reproduire l’environnement de production de chaque projet, simplement, sur votre machine.

Vagrant utilise en effet un système de fichier décrivant l’environnement, le « vagrantfile ». Toute personne rejoignant le projet n’ayant ainsi plus qu’à lancer la commande « vagrant up » pour démarrer un environnement isolé, prêt à l’emploi.

Associer ce fichier à un système de version tel que git nous permet en plus d’avoir un historique des fichier et de permettre de simplifier la mise à jour de l’environnement. Ainsi pour obtenir la nouvelle version de l’environnement, il vous suffit de 2 commandes :

git pull
vagrant up

Cependant, la couche de virtualisation imposé par la technologie utilisé par vagrant peut ralentir votre productivité. Pas nécessairement directement, mais le « feeling » d’une machine virtuelle peut vous frustrer et vous empêcher d’itérer aussi rapidement que vous souhaiteriez.

Mais depuis la révolution Docker, une solution d’isolation et non de virtualisation, une nouvelle solution s’offre à vous !

3. L’utilisation de docker et docker-compose

Nous allons ici combiner 3 solutions techniques afin de de proposer une architecture répondant à tous nos critères :

  • Docker : Conteneur isolé et rapide dans l’exécution
  • Docker-compose : Fichier de configuration permettant d’orchestrer la mise en place d’un ou plusieurs conteneur Docker
  • Git : Gestion de version des version du fichier docker-compose et partage facile de ce fichier

Les conteneurs Docker fonctionne très majoritairement sur Linux, mais le système Docker lui-même existe sur Windows, Mac et Linux, ce qui vous permettra de vous affranchir de l’OS d’exécution de l’environnement.

Docker-compose et le fichier « docker-compose.yml » nous permettra de figer l’environnement et de le rendre parfaitement reproductible. Nous pourrons y décrire l’ensemble de nos besoins en terme de logiciel, tel que nous le verrons plus loin.

Enfin, Git, nous donnera la possibilité de pouvoir rejoindre un projet en « Clonant » un dépôt git et nous apportera un système de version. Cette gestion des versions est importante dans la mesure où elle apportera de la traçabilité en cas de changement d’une des dépendances apportant un problème de comptabilité.

Voyons maintenant comment, concrètement, utiliser ces technologies afin d’obtenir une solution répondant à tous nos critères initiaux et aussi simple à utiliser qu’un « vagrant up », tout en étant plus rapide.

L’idée ici est de créer un dossier comprenant un docker-compose.yml décrivant l’environnement, puis de fournir chaque composant de l’environnement via une image docker disponible sur le docker hub ou via un dockerfile.

Nous allons ici construire un environnement comprenant une base elasticsearch et un environnement python, avec le driver elasticsearch pre-installé dans une version fixé.

Nous aurons donc la structure de dossier suivante :

Voici le docker-compose.yml vous permettant de mettre en place l’environnement:

Ce fichier va donc créer deux containeurs Docker. Un comportant notre base ElasticSearch, et l’autre un environnement Python à partir d’un Dockerfile. Les deux containeurs utiliseront le réseaux de l’hôte, afin d’être le plus transparent possible pendant le développement. Nous définissons également un point de montage d’un dossier (/home/pierre/python) vers /app dans le containeur afin que ce dernier puisse acceder à nos fichier.

Notez l’utilisation des options stdin_open, tty et du lancement de la commande /bin/bash dans le containeur. Ceci aura pour effet de maintenir un terminal ouvert, invisible pour l’utilisateur, afin que le containeur ne se termine pas tout seul.

Le dockerfile utilisé est ici assez standard :

Il ne vous restera plus qu’à utiliser Git afin de pousser cette définition d’environnement vers tous vos collègue.

Voyons maintenant comment utiliser votre environnement :

Supprimer cet environnement ne laissera aucune trace sur votre ordinateur :

Vous savez maintenant comment utiliser Docker pour développer sans frustration !

Pour plus d’information sur docker, docker-compose et git, voici leurs documentation respectives :

Posted in Non classé | Leave a comment

#play14 Luxembourg

 

Nous sommes allés à la découverte de cet événement prenant place à différentes localisations – principalement européennes – lors de la session Luxembourg 2017 (du 23 au 25 Avril).

Les organisateurs le décrivent comme une « non-conférence » internationale où se retrouvent des personnes enthousiastes qui partagent l’idée commune que jouer est le meilleur moyen d’apprendre et de comprendre.

On peut y développer nos compétences de facilitateur, notre capacité à accompagner les changements, à favoriser notre créativité et améliorer nos facultés d’innovation (toute ressemblance avec certains principes agiles ne serait absolument pas fortuite … 😊).

Chaque participant peut également être contributeur, en proposant d’animer un atelier selon un planning collaboratif déterminé par le collectif.

Telles sont les promesses annoncées par les organisateurs sur le site play14.org.

 

Tous ces éléments ont suscité chez nous une très forte curiosité et nous étions trois à aller découvrir et essayer cet événement prometteur. Tient-il ses promesses ? Que peut-on y faire et y apprendre ?

Si cela vous a également éveillé l’esprit et que vous souhaitez un avis objectif avant de vous lancer dans l’aventure, nous vous avons préparé un petit test synthétique de cette mystérieuse #play14.

  1. Le terme de « Non-conférence »

Il n’y a effectivement pas eu de place pour des discours théorique où l’orateur est le seul contributeur du moment. Que ce soit lors de jeux, d’ateliers, de workshops, la répartition théorie/pratique est généralement idéale puisque tout est facilement réparti : « Règles – Pratique (et Facilitation) – Résultats/débrief »

  1. Evènement international

Luxembourg, France, Belgique, Allemagne, Royaume-Uni, Italie, Pays-Bas, Russie, Roumanie, Inde… Les origines des participants sont incroyablement variées. Une majorité francophone existe, mais il est hors de question de se priver du potentiel de chacun ou de créer des groupuscules… ! La pratique de l’anglais est indispensable et partagée par tous. Elle peut constituer un frein pour certain, et un réel atout pour d’autres. Ce n’est donc pas un problème, mais une contrainte à prendre en compte avant de s’inscrire.

  1. Organisateurs et Participants

L’accueil est réellement chaleureux et toute l’équipe organisatrice insuffle une incroyable énergie à l’ensemble du groupe. La grande majorité des participants est également désireuse d’apprendre, d’échanger, de confirmer ou d’infirmer leurs raisonnements et le respect des idées de chacun est omniprésent. Nous semblions tous être convaincus que la voie ludique est probablement le meilleur moyen d’apprendre, et de mettre le doigt sur des choses invisibles ou difficilement cernables dans un environnement « classique ». Coachs agile, Experts, Managers, Leaders Technique, Développeurs ou encore Professeurs ne sont qu’une partie de la palette de profils représentant notre groupe de passionnés et de curieux. Des habitués ou des convaincus des éditions précédentes sont également présents, ce qui assure un niveau de qualité plutôt admirable.

Les participants sont donc la principale source de réussite de l’évènement, et cela amène parfois à certains ateliers peu intéressants alors que d’autres sont géniaux. En tant que participant cela peut être frustrant dans certains cas, mais c’est une véritable force pour tous ceux voulant s’essayer à la facilitation, ou tester de nouvelles choses avec un public averti et dont l’œil critique ne les rendra que meilleurs.

  1. Développer son agilité

Les différents termes utilisés dans les descriptifs comme point de focus sont non sans rappeler l’agilité. Preuve en est de la forte présence de pratiquants réguliers de l’agilité.

Afin d’exploiter au mieux le potentiel de cette #play14, nous nous sommes – autant que possible – répartis sur les diverses locations afin de participer à un maximum d’ateliers et d’être en mesure de regrouper ces expériences acquises. Certains n’ont pas retenu notre attention car jugés trop situationnels ou peu facilement exploitables sur nos cas concrets, mais un certain nombre se sont révélés être de très bonnes découvertes, si ce ne sont de réels coups de cœur.

Compilation des activités auxquelles nous avons participé :

  • Ball Point Game

Durée : De 30 minutes à 1 heure en fonction du nombre de participants

Nombre de participants : Un minimum de 8 personnes, sans limite maximale (diviser si besoin en groupes de 10-12 personnes max)

But et intérêt : Faire circuler le plus de balles possible entre tous les participants selon des règles définies, dans un temps imparti. La coopération entre tous sera la clé pour pratiquer l’amélioration continue afin de faire le meilleur score possible, essai après essai.

Limites/Remarques : Le facilitateur est très important et doit veiller à ne pas faire traîner en longueur l’exercice si ses limites en sont atteintes, au risque de perdre l’attention des participants, ce qui irait dans le sens inverse du but de cette activité.

  • Spell Your Name

Durée : 5 à 10 minutes

Nombre de participants : Groupes de 6 à 10 personnes

But et intérêt : Ecrire les prénoms des autres membres du groupes sur une feuille selon différentes règles, afin de mettre en évidence que le focus est bien plus efficace que le multi-tasking.

Limites/Remarques : Exercice très rapide, mais terriblement efficace.

  • Cynefin Lego

Durée : 1h à 1h30

Nombre de participants : Groupes de 4 à 8 personnes

But et intérêt : Expliquer le Framework Cynefin à travers la manipulation de Legos en phases successives de difficultés croissantes. Apprendre comment agir en fonction de la complexité de la situation et mise en avant de l’importance de la communication et du contrôle qualité commun.

Limites/Remarques : Le contenu des boîtes de Lego utilisées doit être relativement varié et fourni.

  • Kanbanzine

Durée : ½ à 1 journée (pour en exploiter tout le potentiel)

Nombre de participants : Entre 6 et 10 personnes.

But et intérêt : Approfondir ses connaissances ou découvrir Kanban, ses outils métriques et organisationnels, à l’aide d’un jeu de rôle nous plongeant dans l’univers d’édition journalistique.

Limites/Remarques : C’est long, très long. La facilitation est également extrêmement importante et pas aussi simple que sur d’autre ateliers/jeux. Le concept est très intéressant et très bien conçu, mais il paraît assez lourd et difficile à mettre en œuvre. A réserver pour des équipes voulant absolument apprendre et pratiquer quasi exclusivement Kanban.

  • Sketch Noting

Durée : 1h

Nombre de participants : Pas de limite.

But et intérêt : Apprendre à modéliser rapidement des objets à travers des dessins faciles pour mettre en valeur des éléments de présentations notamment. On peut appeler cela de la facilitation graphique.

Limites/Remarques : Un certain talent et un attrait pour l’esthétique textuelle sont nécessaires.

  • 5 squares

Durée : Environ 30 minutes

Nombre de participants : Groupes de 5 à 6 personnes

But et intérêt : Chacun doit recomposer un carré à l’aide d’un certain nombre de morceaux de papier de formes différentes, dans son espace de travail réservé, avec des règles strictes. Ce jeu prouve l’efficacité de la collaboration et de l’esprit d’équipe afin de privilégier des résultats communs et une performance globale plutôt que des individualités.

Limites/Remarques : Une diversité dans les caractères/comportements des membres d’une équipe améliorera d’autant plus les leçons et l’expérience tirées de ce jeu.

  • Lego Serious Play for Meetings

Durée : Pas de limite basse ou haute, flexible en fonction du besoin.

Nombre de participants : Pas de limite.

But et intérêt : Manipuler des Lego afin de construire des représentations visuelles de nos émotions/ressentis sur un sujet, afin de laisser place à l’interprétation et à l’expression créative de chacun. Cela peut être utilisé pour tous types de réunions, brainstorming, rétrospective, inclusions… L’essentiel étant que chacun laisse libre cours à son imagination et à une parole spontanée afin de s’exprimer le plus librement possible.

Limites/Remarques : Certaines personnes peuvent avoir des difficultés lors de la prise de parole puisqu’il est nécessaire d’être relativement spontané mais c’est certainement aussi la grande force de cette activité.

  • Kapla DevOps

Durée : 30 à 45 minutes

Nombre de participants : 2 équipes de 3 à 4 personnes.

But et intérêt : Réaliser une tour Kapla selon des stories définies, puis déplacer (livrer) cette construction d’un environnement (place) à un autre. L’intérêt est de démontrer l’importance capitale d’une bonne communication et synchronisation entre les équipes réalisant et maintenant le produit. Avoir les mêmes bases, être informés de tout changement sans quoi l’équipe assurant la pérennité dans le temps du projet risque de rencontrer de nombreux problèmes, créateurs de fortes tensions entre les équipes.

Limites/Remarques : Le fond est très intéressant et le concept bien choisi. La facilitation reste toutefois très importante et nous pensons qu’il y avait mieux à faire pour exploiter le potentiel de ce jeu. Les organisateurs étaient alignés sur le feedback du groupe et ont assuré travailler sur ce jeu afin de l’améliorer et lui donner une autre dimension les prochaines fois.

  • Barnga Cards Tournament

Durée : 45 minutes à 1 heure

Nombre de participants : Groupes de 3 à 4 personnes.

But et intérêt : La communication orale est interdite dans ce tournoi aux règles définies initialement pour chaque table. Les vainqueurs et perdants de chaque manche de 5 minutes changent de table. Avec cette impossibilité de parler, les incompréhensions dues aux différences de règles entre les groupes deviennent de plus en plus fortes, et les caractères dominant, les alliances s’expriment. C’est un excellent moyen de démontrer que chacun doit être pleinement conscient des règles de jeu de chacun et comprendre la vision des autres. Sans quoi, certains s’effacent pendant que d’autres imposent leurs règles, créant des tensions et des frustrations pour les autres.

Limites/Remarques : Les concepts de fond sont compris dès la 2 ou 3ème rotation. Seulement continuer encore permet l’émergence de personnes arrangeant la situation à leur avantage, ou d’autres se laissant complètement faire, ce qui amène de nouveaux points de réflexion et de risques dans le cadre d’une équipe de travail.

  • Solve the Maze

Durée : 1h minimum

Nombre de participants : Groupes de 6 à 10 personnes. (1 facilitateur par groupe)

But et intérêt : Être la première équipe à résoudre le labyrinthe invisible. Chaque erreur nécessite un retour en arrière immédiat en suivant le même parcours qu’en avançant. Le facilitateur doit faire preuve d’une concentration extrême pour guider chacun. Des règles viennent compliquer la tâche et la compétition entre les équipes dynamise l’esprit collaboratif et fait émerger des idées de progression chez chacun.

Limites/Remarques : La représentation au sol de la grille du labyrinthe n’est pas forcément aisée et peut prendre un peu de temps.

 

Conclusion :

Ce qu’on a aimé Ce qu’on a moins aimé
L’autonomie… … risquée et capitale (pas de plan B)
L’accueil, l’organisation Certains ateliers
La diversité des ateliers Le monopole d’attention de certains Coachs (qui s’efface vite)
L’endroit parfaitement adapté

 

Cet événement est incroyable de par son organisation et sa potentielle richesse de contenu, amenée par la diversité incroyable des personnes y participant. C’est également là sa faiblesse puisqu’il est de ce fait totalement possible de n’avoir que peu de résultats de par le peu d’implication ou de disponibilité de chacun. Mais après tout, lorsqu’on parle de jeux et d’agilité, y a-t-il réellement des personnes peu susceptibles d’adhérer au concept et restant en retrait ?

Nous sommes désormais encore plus convaincus que la voie ludique est probablement une des meilleures manières d’apprendre et de mettre en avant des choses qui ne pourrait pas l’être par des voies classiques. Nous avons adoré cet évènement et disposons d’une réelle envie d’y participer à nouveau, en étant cette fois plus acteur et force de propositions afin d’enrichir encore plus ce rassemblement passionné.

Vous y croisera-t-on la prochaine fois ? 😊

Peggy, Jean-Mi et Thierry

Posted in Non classé | Leave a comment

Vous n’avez pas encore votre mur ?

Le management visuel, Agile board, mur ou radiateur d’informations, Obeya… quel que soit le nom que vous lui donnez, est une pratique utilisée au sein de la majorité des équipes Agile expérimentées. Quand il est mis en place, il peut très vite devenir central et apporter de nombreux bénéfices tant à l’équipe qu’au management.

Un mur d’informations, c’est un outil de management

Qu’il soit physique ou électronique, c’est avant tout un outil de management au sens où il doit permettre de constater l’état de santé d’un projet comme par exemple l’activité de l’équipe en quasi temps réel, les obstacles identifiés…permettant ainsi au management, s’il en fait l’effort, d’intervenir au plus tôt.

Pour être efficace, « Regarder un mur d’informations » ne doit pas prendre trop de temps ni être très compliqué et le bénéfice doit se traduire en actions concrètes. Le débat se situe donc dans le choix à faire entre:

  • un mur d’informations physique, facile à regarder à condition de pouvoir se déplacer dans la pièce dédiée à l’équipe et
  • l’utilisation d’un ou plusieurs outils électroniques partagés dans lesquels il faut parfois naviguer entre plusieurs vues pour trouver la bonne information.

Un mur d’informations, c’est vivant

Comme dans un cadre Agile, le flux d’activités est émergent, le board doit être facile à mettre à jour. On privilégiera donc qu’il reflète l’activité réelle de l’équipe pour garantir la transparence et la simplicité. Les outils électroniques ne permettent bien souvent pas une flexibilité équivalente à ce que propose la version physique où il est très simple d’ajouter/retirer des colonnes ou des swimlines, de changer le nom des colonnes et cela sans dommage collatéral.

Un mur d’informations, ça rassemble

Un mur est aussi un point de rencontre privilégié pour les équipiers. Il permet par exemple de se rassembler pour le  et contribue ainsi à établir l’esprit d’équipe et le sens du travail collaboratif, là où les outils électroniques retranchent les équipiers dans leur bulle. C’est également un argument de plus pour favoriser la colocation de l’équipe complète ou au moins les interactions quotidiennes avec le product owner.

Un mur d’informations, c’est visible de tous

Le management visuel de l’équipe doit être à la vue de celle-ci. Il doit suffire de lever ou de tourner la tête pour le voir. De plus, en rendant visite à l’équipe, n’importe quelle partie prenante du projet doit être en mesure de constater où l’on en est, au jour le jour.

Un mur d’informations, c’est un booster pédagogique

Dès la mise en place, monter la version physique du mur est un moment « ludique » pour l’équipe. S’appliquer à faire un BEAU board sort les personnes de leur quotidien et fait partie intégrante d’une transformation agile. Pour embarquer les équipiers et leur faire comprendre le chemin qui est pris, cela permet que chacun consacre le temps qu’il faut pour regarder et analyser le premier flux d’activités qui est mis en place.

L’importance de la mise à jour physique

La mise à jour physique permet à toutes les parties prenantes de se rendre compte de l’avancée du travail. Cela est beaucoup plus silencieux via les outils électroniques. Le déplacement des cartes de la gauche vers la droite permet souvent aux équipiers de constater l’avancement du travail ou, au contraire, de prendre conscience qu’il est laborieux. C’est également un bon moyen de se préparer au daily meeting, de donner à tous les clefs pour en suivre correctement le déroulement et faire en sorte qu’il soit efficace.

Transparence

Physique ou électronique, le management visuel est la première étape vers une posture de transparence. Un « beau » mur physique est un support de communication pour toutes les personnes qui passent devant, et peut aussi à ce titre être un vecteur de curiosité, voire de viralité.

Une invitation à la prise de recul

Une autre force du management visuel physique est de prendre du recul et de faire face à l’état du système. Par exemple, constater une accumulation de post-its dans une colonne permet d’un coup d’œil de prendre conscience d’un éventuel goulet d’étranglement.

Avec de « bonnes » limites !

Les limites physiques du mur vont contribuer à limiter l’en-cours. Par exemple, il ne sera pas possible physiquement de surcharger une colonne à l’image des WIP limits Kanban !

Se lancer et créer SON « mur »

Il « suffit » d’un mur, de post-its, de scotch pour monter le radiateur d’informations le plus pertinent. Bien entendu, tous les boards auront des points communs. Mais il n’existe pas d’outil électronique qui permette de créer le « mur » qui sera le plus efficace pour vous. Généralement, les équipes ne se limitent pas à la visualisation du processus de développement : elles ajoutent des maquettes du produit à développer, un suivi des obstacles, des indicateurs spécifiques, des schémas d’architecture, des diagrammes, les Definitions of Done et autres règles communes…

Contraintes matérielles

A l’heure des locaux modernes, la plus grande difficulté des équipes est souvent de trouver le mur physique qui pourra accueillir les post-it, paperboards et autres collages plus ou moins temporaires. Voici toutefois 2 alternatives à expérimenter :

  • investir dans des whiteboards sur pied (modèles roulants ou fixes)
  • utiliser des bandes de feuilles statiques (adhérence garantie sur vitrage, cloisons métalliques, boiseries, …) : taper « Magic Whiteboard ».
  • utiliser du rouleau adhésif coloré en 3mm sur 3m pour de belles colonnes droites et repositionnables…

Le mot du coach

Mettre en place le mur c’est bien, le maintenir et le mettre à jour c’est mieux ! Je rappelle que ce n’est pas le travail d’une seule personne mais que toute l’équipe doit s’en préoccuper de la rédaction des post-its à la mise à jour des indicateurs… D’ailleurs si ce n’est pas le cas, c’est peut-être le signe qu’il y a une incompréhension dans les rôles et responsabilités de chacun…

Je suis une grande adepte du format physique et j’oriente souvent les équipes que j’accompagne à utiliser ce format bien au-delà du « simple » Scrum board : storymapping vivant, tableau des obstacles, board des « avant-ready », portfolio Kanban, release planning,… il faut adapter la proposition au cas par cas et laisser l’équipe créer et adapter ses propres outils. Bien sûr lorsqu’il y a des difficultés de colocalisation, la version électronique prend le relais ! Certains rêvent même de tableaux numériques tel Tom Cruise dans Minority report ;o)

Et vous, où en êtes-vous ?

Posted in Non classé | Tagged , , | Leave a comment

Considérons React Native

Très rapidement, React est une librairie JavaScript créée par Facebook (utilisée notamment par Facebook, Instagram, Netflix, AirBnB, Deezer, eBay etc…) pour élaborer des interfaces utilisateur, et magnifique le meilleur mot pour la décrire… je vais à présent tâcher de vous en convaincre !

React / Component / Props



Actuellement la plupart des applications mobiles écrites en JavaScript utilisent Cordova, ou un framework basé dessus comme Ionic. Avec ce choix vous n’allez pas vous faciliter la tâche en faisant des appels à une API qui rend du JS et de l’HTML dans une Webview ! C’est un choix de vie…

Problématique : comment faire pour faire bénéficier à votre utilisateur, au travers d’une application hybride, de la même expérience que celle offerte par une application native ? scrolling acceleration, clavier, navigation fluide…

J’AI LA SOLUTION

« React Native c’est pas vraiment du natif. »

Un collègue apprécié (parti trop tôt…).

Bien que ce soit du JavaScript qu’on produise avec React Native, nos components seront rendus en tant que widgets natifs de la plateforme ; aussi si vous avez écrit des applications en Java ou en Objectif-C vous reconnaitrez immédiatement certains des components (écrits en Swift, Obj-C ou Java).

React a énormément changé l’approche dans la constructions d’interfaces utilisateur, par son ‘output of state’, et la facilité de débogage d’une application. Fini de penser à tous les chemins possiblement emprunté par un utilisateur : concentrez-vous sur les états de vos components. React Natif apporte ainsi un nouveau paradigme dans l’écriture d’applications.

Par exemple, au lieu d’utiliser une <div> comme en web, on va utiliser une <View> pour rappeler UIView et android.view. Aussi lorsque les données de votre component changent, React Natif calcule ce qui doit être modifié et effectue les appels nécessaires à tous les widgets d’UI native affichés. Et c’est rapide ! 60 fps ! Le JS est exécuté sur son propre thread, séparé du thread de l’UI principale, donc même si votre application propose une logique complexe, vous réussirez à proposer la meilleur des UX.

Un bon starter kit pour mesurer les capacités de la technologie et vous mettre dans le bain  : https://github.com/start-react/native-starter-kit

Conclusion

En conclusion (et toujours selon moi !) vous vous facilitez la vie en choisissant React Natif : réduction des coûts de développement, 1 app / 2 plateformes. Ensuite, qui propose cet éco-système autour d’un framework d’applications natives cross-platform ? Ajoutez y Redux (un conteneur d’état) et vous allez atteindre des sommets, et en plus vous pourrez profiter d’une communauté riche et réactive (sans mauvais jeu de mot) !

baba out

Posted in Non classé | Leave a comment

Introduction au framework ITIL

Le framework ITIL® est de plus en plus utilisé le monde de l’IT.
Vous en avez peut être déjà entendu parler.
Suite à une formation récemment suivie, j’ai souhaité vous faire une présentation des principes ITIL®.

Qu’est-ce qu’ITIL® ?

ITIL® signifie : IT Infrastructure Library.
Finalement ceci vous avance peu.
Avant d’aller plus loin faisons un peu d’histoire.

Dans les années 80, répondant à une dépendance croissante envers les Technologies de l’Information, le gouvernement britanique (sous l’impulsion de Mme. Thatcher) a élaboré un ensemble de recommandations.
ITIL® est donc un recueil de bonnes pratiques basées sur une approche par processus, destiné aux organisations informatiques qui délivrent des services complets à leurs clients.
ITIL® n’impose rien (non prescriptif), n’est pas orienté fournisseurs/outils et n’est pas un standard.

La finalité est d’organiser un référentiel de gestion de services informatiques rendus sur la base d’une infrastructure IT.
Cette gestion est également connue sous le nom de ITSM (« IT Service Management »).

Concrètement comment cela se présente ?

Actuellement nous sommes à la version 3 d’ITIL®.
Le noyau (core) de la documentation est composé de 5 livres qui représentent chacun une phase du cycle de vie de l’ITSM.
De la documentation additionnelle est disponible : publications complémentaires et supports web (glossaire, template)
Cette bibliothèque d’information décrit notamment 26 processus et 4 fonctions.

Quels sont les concepts de base ?

ITIL® est un framework orienté client, basé sur des concepts dont voici les principaux.

Le but d’un service IT est de créer de la valeur pour les clients.

  • ITIL® définit l’utilisateur comme celui qui utilise le service (ex : opérateur de saisie, agent de transfert).
  • Il peut être différent du client, celui qui définit le service et qui l’achète (ex : CEO).
  • Les deux types d’interlocuteurs parlent à un fournisseur de Service IT (IT Service Provider).
  • La valeur d’un service est composée de son utilité (fonctionnalités) et de sa garantie (niveaux de service : capacité, disponibilité, sécurité, continuité).

La notion de phases de cycle de vie de l’ITSM a été introduite précédemment.

Mais quelles sont ces phases ?

ITIL® décrit les 5 phases du cycle de vie suivantes :

  • Service Strategy :
    L’objectif de cette phase est de définir la stratégie des services à implémenter.
    C’est à dire, comprendre les besoins des clients et repérer les avantages concurrentiels de son entreprise afin d’adapter au mieux l’offre des services proposés dans le portefeuille de services.
  • Service Design :
    Gestion du catalogue de services (y compris leur spécifications techniques) correspondant à la stratégie définie dans la phase précédente.
    Le catalogue de services correspond uniquement à la partie opérationnelle du portefeuille des services.
    C’est à dire aux services que le client peut acheter/utiliser.
  • Service Transition :
    Développer et intégrer les nouveaux services (ou adaptation de services existants) dans l’environnement cible.
  • Service Operation :
    Maintenir les services dans les environnements supportés afin qu’ils continuent à fonctionner comme attendus (sans dégradation de performances).
    L’exploitation des services est la partie du cycle de vie où les services et la valeur sont effectivement livrés.
  • Continual Service Improvement :
    Mettre en œuvre des plans d’amélioration des services de manière incrémentale et continue.

 

Itil_Lidecycle

Représentation des 5 phases du cycle de vie

Quelles sont les différentes fonctions ?

ITIL® définit une fonction comme une unité d’une organisation (entreprise) qui est spécialisée pour exécuter certains types de travail.
ITIL® décrit 4 fonctions au sein du fournisseur de service IT :

  • Service Desk :
    Le Service Desk a un rôle de centralisateur. C’est le Single Point Of Contact pour les utilisateurs (SPOC).
    Il est en charge de gérer toutes les demandes clients, qu’il devra catégoriser et prioriser afin de déclencher le processus adéquat.
  • Application Management :
    Est garante du savoir et de l’expertise concernant les applications.
    En cas de besoin d’expertise concernant le software (lors d’une escalation) c’est vers cette fonction qu’il faudra se diriger.
  • IT Operational Management :
    Est garante de la stabilité de l’environnement et de la livraison des services.
    Par exemple le monitoring des KPI est notamment pris en charge (sous-fonction IT Operational Control) ainsi que la gestion des infrastructures (Datacentre…) (sous-fonction Facilities)
  • Technical Management :
    Est garante du savoir et de l’expertise concernant les équipements matériels.
    En cas de besoin d’expertise concernant le hardware (lors d’une escalation) c’est vers cette fonction qu’il faudra se diriger.

Que représentent les processus ?

ITIL® indique qu’un processus a caractéristiques :

  • Il répond à un évènement spécifique
  • Il génère un résultat attendu
  • Ce résultat est délivré à un client
  • Le processus est mesurable (en coût, en qualité…)

ITIL® décrit 26 processus nécessaires à l’ITSM.
Rassurez-vous nous n’allons pas décrire (ni lister) les 26 processus.
L’ensemble des processus est réparti sur les différentes phases du cycle de vie de l’ITSM.
Certains sont donc plus liés à la stratégie et d’autre plus orientés opérationnels.
Voici quelques exemples :

  • La gestion des évènements (phase Service Operation)
  • La gestion des incidents (phase Service Operation)
  • La gestion des problèmes (phase Service Operation)
  • La gestion des accès (phase Service Operation)
  • La gestion de changement (phase Service Transition)
  • La gestion du portefeuille de services (phase Service Strategy)
  • La gestion de la capacité (phase Service Design)

Comment implémenter ces best practices ?

ITIL n’étant pas prédictif rien n’est imposé.
Dans la mesure où le spectre d’application est large (puisqu’il couvre l’ensemble des cycles de la livraison de services informatiques), c’est un atout !

En effet, vouloir implémenter directement l’ensemble des 26 processus est beaucoup trop long et risqué.

Il est plus efficace de trouver quelques processus qui permettront des Quick Win que l’on peut implémenter rapidement et de réitérer ensuite l’opération.
Généralement ce sont les processus opérationnels qui sont implémentés en premiers.

On peut penser notamment aux processus suivants :

  • Request Fulfilment :
    Ce processus est lié aux demandes des utilisteurs (réinitialisation de password, création d’un nouvel utilisateur, installation d’un logiciel…)
  • Incident Management :
    Un incident dans ITIL® décrit toute perturbation (actuelle ou future) impactant la livraison totale ou partielle du service.
    L’objectif de ce processus est de restaurer aussi rapidement que possible la livraison du service au niveau attendu.
  • Problem Management :
    ITIL® défini un problème par la cause, inconnue, sous-jacente d’un ou de plusieurs incidents.
    L’objectif de ce processus est de trouver l’origine est de proposer une solution définitive (qui devra être évaluée par le processus de changement Change Management)

Ensuite on sélectionne à nouveau quelques processus et on recommence l’implémentation.

Pourquoi ne pas oublier la Gestion de la connaissance ?

Toutes ces fonctions et processus interagissent entre eux.
Afin d’être le plus efficace possible, les différentes informations (spécifications techniques, configurations, erreurs connues…) doivent être stockées dans des bases de données et accessibles par les autres fonctions/processus.
L’ensemble de ces bases de données forme le Service Knowledge Management System (SKMS).

Pour être plus concret, prenons comme exemple les processus de gestion d’incidents et de gestion des problèmes (qui ont été décrits précédemment) :
Le responsable de la Gestion des Problèmes renseigne les erreurs connues dans une base de données (Known Error DB) appartenant au SKMS.
ITIL® définit une erreur connue comme un problème qui a une cause sous-jacente connue et pour laquelle un workaround existe. Le tout étant documenté.
Ces informations, renseignées dans le SMKS, permettront au responsable du processus de la Gestion des Incidents de répondre au plus vite à l’utilisateur avec la réponse adéquate.

Quels sont les gains apportés par ITIL® ?

L’adoption des bonnes pratiques de l’ITIL® par une entreprise permet d’assurer à ses clients (internes comme externes) un service répondant à de hautes normes de qualité.
ITIL® permet, grâce à une approche par processus clairement définie et contrôlée, d’améliorer la qualité des SI et de l’assistance aux utilisateurs en créant notamment la fonction Service Desk.
ITIL® est finalement une sorte de « règlement intérieur » du département informatique des entreprises qui l’adoptent.

Les bénéfices pour l’entreprise sont une meilleure traçabilité de l’ensemble des actions du département informatique.
Ce suivi amélioré permet d’optimiser en permanence les processus des services pour atteindre un niveau de qualité maximum de satisfaction des clients.

En conclusion

En se basant sur le concept Adopt and Adapt, les bonnes pratiques ITIL® sont applicables aussi bien par les petites structures que par les grandes entreprises.
Elles permettent de mieux gérer la livraison de services informatiques en contrôlant le niveau de service fournit et en proposant des améliorations en continu.
Le framework ITIL® est compatible avec des normes (norme ISO 20000) et autres standards mais également avec des méthodologies (Prince2 ou Agile).

Bien évidemment cet article n’est qu’une brève introduction à ITIL®.
Toutes les notions et concepts n’ont pas été présentés (rôles, configuration item, Cycle de Deming…).

Si vous êtes prêt à rentrer dans ce nouveau monde, n’hésitez pas à cliquer sur ces liens qui vous seront ITIL :
http://www.itilfrance.com/
https://www.axelos.com/best-practice-solutions/itil

Sources
https://ced421.files.wordpress.com/2013/06/itil1.jpg

Posted in Non classé | Tagged , , | Leave a comment

Retour sur DevOps REX

Le 28 novembre dernier se tenait la conférence DevOps REX au Grand Rex à Paris. Digne héritière des précédents DevOpsDays Paris 2013 & 2015, cette édition était centrée autour de Retours d’Expériences. DevOps REX en quelques chiffres c’était :

  • 400 Participants ;
  • 16 Sponsors ;
  • 9 Conférences ;
  • 1 Lieu d’échange : l’espace social.
devopsRex

Une journée complète consacrée à des REX francophones : un pari osé !

 

DevOps : un seul mot, des définitions différentes mais une vision partagée

DevOps est certainement l’un des termes les plus en vogue dans notre métier ces dernières années. Pour certains il s’agit de pratiques réservées au monde des startups, des géants du Web. Pour d’autres, ce n’est qu’une tendance passagère ou un ensemble d’outils. Malheureusement, il reste encore beaucoup de mythes autour de DevOps. Cette conférence n’a pas pour but de démystifier tout ça. D’autres l’ont fait avant et il existe désormais une bibliographie assez complète autour du sujet.

Nous entendons beaucoup de success-stories liées à DevOps. Nous souhaitons tous tirer les bénéfices d’une telle approche sans savoir réellement ce que c’est ni vraiment par où commencer. DevOps REX se consacre aux témoignages et met en avant des exemples concrets de mise en place au sein de grandes structures comme Microsoft, Orange et la Société Générale. Grâce à leurs retours, les speakers nous ouvrent la voie en partageant à la fois leurs succès et leurs échecs.

Comment définir DevOps ?

Grâce à l’acronyme mettant en lumière ses valeurs fondamentales :

C A (L) M S

pour Culture, Automation, Measurement, Sharing et bien entendu le dernier arrivé : Lean.

DevOps est un mouvement visant à aligner le SI sur les besoins de l’entreprise. Autrement dit, l’objectif premier est de délivrer de la valeur. Durant cette journée deux sujets ont été soulignés à plusieurs reprises et ont retenu mon attention. Vous les retrouverez ci-dessous.

Une approche Top-Down & Bottom-Up

L’attente est souvent forte du côté des développeurs vis à vis de DevOps et une certaine frustration peut naitre dans les équipes lorsqu’elle ne fait pas écho dans le reste de l’organisation.

Une telle transformation nécessite avant tout un engagement de la direction. Cela démarre par une prise de conscience sur les besoins et les raisons d’une telle démarche. Elle doit ensuite être accompagnée d’un sponsoring fort puis matérialisée par une prise de décision de manière formelle et présente à tous les niveaux.

Une approche « bottom-up » sans soutien du management ne suffit pas et une approche « top-down » sans réalité du terrain non plus. Il est nécessaire d’avoir les deux. Cette double pression maximisera les chances de réussites.

L’importance de la mesure

Le monitoring classique revient souvent à prendre le pouls d’une application pour connaitre son état au présent ou rapporter ce qu’il s’est passé jusqu’ici (regard vers le passé). Ce n’est pas seulement de reporting dont nous avons besoin mais de feedback rapide : comprendre ce qu’il se passe pour anticiper le futur et piloter ! Il faut donc :

  1. Récolter un maximum d’informations car toutes les problématiques ne sont pas connues à l’avance ;
  2. Diffuser l’accès à ces informations et notamment à ceux qui en ont besoin pour prendre des décisions ;
  3. Penser mesure et métrologie dès la conception.

Il est nécessaire d’intégrer au plus tôt ces besoins dans l’écriture des User Stories en mettant dans la boucle tous les acteurs concernés. Par exemple : les équipes de support sauront mieux que personne indiquer les indicateurs dont elles ont besoin pour assurer le support d’une fonctionnalité.

Pour garantir un certain niveau de qualité, il faut mettre en place les outils et les mesures adéquates. Ces métriques permettent de définir les pistes d’amélioration et interviennent à différents niveaux :

  • L’organisation : pour définir sa stratégie (Lead-time, WIP, fréquence des livraisons, …)
  • La chaîne de production logicielle : pour évaluer la vélocité des développements, la dette technique.
  • La qualité du service (disponibilité, performance, fiabilité, …)
  • L’usage des outils  : pour mesurer l’adéquation entre le produit et les attentes des utilisateurs

Pour conclure, DevOps est surtout un état d’esprit plutôt qu’une suite d’outils.

Envie d’en savoir plus ? Je vous invite à (re)voir les conférences sur la chaine youtube de DevOps Rex ! 😉

Posted in conférence | Tagged | Leave a comment

Développer des applications mobiles avec Ionic 2

Ionic logo

Qu’est ce que Ionic ?

Ionic est un framework de développement d’applications mobiles hybrides. Il s’est entouré de précieux alliés, tels que Apache Cordova (ex Phonegap) et AngularJS.

Pour pouvoir développer ses applications mobiles, Ionic se base donc sur Cordova, ce qui veut dire que tous les plugins Cordova permettant d’accéder aux fonctionnalités natives des mobiles peuvent être utilisés dans un projet Ionic. Avec Cordova, il est également possible de packager son application HTML et de la déployer sur les smartphones Android, iOS ou Windows Phone.
Mais il y rajoute une surcouche, et y joint notamment AngularJS, permettant l’ajout du MVC, ainsi que le CSS permettant de se rapprocher au mieux du style des applications natives (Android et iOS).

cordova-ng-ionic

Ionic c’est également une plate-forme offrant tout un panel d’outils destiné à faciliter la tache au développeur (plus de détails ci-dessous).

Applications mobiles : développement natif ou hybride ?

Lorsque l’on veut développer une application mobile, cette question est souvent l’une des premières que l’on se pose.

Une application mobile native permettra de mieux intégrer toutes les fonctionnalités du smartphone (GPS, appareil photo, …), et permettra également de mieux gérer la mémoire de l’appareil. Le développement natif est la solution qui offrira de meilleurs résultats en ce qui concerne la performance en terme de fonctionnalités.

Cependant, cela pose des soucis en terme de développement et de déploiement. En effet, aujourd’hui les applications sont le plus souvent destinées aux personnes possédant des appareils iOS et Android (voire Windows Phone). Le développement natif impliquera de doubler (voire tripler) le code source des applications, et il faudra également maintenir ces trois applications différentes (tout ça induit un coût supplémentaire).

Une application hybride est une application développée en HTML5/CSS3, qui s’exécute ensuite sur les smartphones dans une Webview. Cela permet d’avoir une application déployable sur tous les appareils, téléchargeable sur les différents stores (Google Play, App Store) et permettant d’utiliser les fonctionnalités du téléphone.
De plus, avec des frameworks comme Cordova, il est possible d’accéder aux APIs natives des smartphones pour utiliser appareil photo, notifications push,…
Cela permet d’avoir un seul code source pour toutes les plateformes mobiles (réduction du coût de développement et du coût de maintenance).

Mais il reste tout de même des freins à ce type de développement. En effet,il n’existe pas de composants UI standardisés, c’est-à-dire qu’il est possible de faire des applications pas (ou peu) adaptées à l’écran des smartphones. Et comme il n’y a non plus pas de standardisation dans la manière de développer, il faut également faire attention au contenu que l’on met dans nos pages HTML, en prenant en compte le fait qu’un smartphone n’a pas la même puissance qu’un ordinateur (même si aujourd’hui ils le sont de plus en plus). C’est moins de performance que les applications natives.

La solution Ionic

Ionic se base sur Cordova. Il va donc intégrer les outils permettant de builder l’application HTML en exécutable (pour Android, iOS ou Windows Phone). Il est également possible d’utiliser tous les plugins Cordova existant et d’accéder aux fonctions natives des smartphones.

A tout ça, on ajoute les fonctionnalités d’AngularJS : le modèle Vue/Contrôleur, ainsi que les différentes directives permettant de faciliter le développement.

Ionic propose ses propres outils en plus de Cordova et AngularJS.
En effet, avec Ionic, nous avons la standardisation des applications hybrides qu’il nous manquait. Ionic propose des styles CSS propres à chaque plateforme, permettant de développer des application au design très ressemblant à celui des applications natives. Ces styles CSS sont très facilement personnalisables, car la technologie utilisée est SASS (Syntactically Awesome Stylesheets, plus d’info ici: http://sass-lang.com/). Un système de variables Sass a été mis en place afin de pouvoir très facilement personnaliser le style de composants précis.
Par exemple, pour modifier la couleur de fond de l’application, il suffira de modifier la valeur de la variable: $background-color
Si vous voulez modifier la couleur seulement pour l’application iOS: $background-ios-color
Avec Sass, vous pouvez également ajouter très facilement vos propres feuilles de styles.
Et tout ce système est indépendant du code source javascript/HTML de votre application !

Ionic propose également des composants UI déjà tous faits, prêts à être utilisés, et dont le style est adapté en fonction de la plateforme sur laquelle sera déployée l’application. Cela permet un gain de temps dans le développement des interfaces.

Les outils Ionic mis à la dispotion du développeur

Ionic a mis au point son CLI (Command Line Interface), permettant d’utiliser plusieurs outils capables de faciliter la vie aux développeurs. Voici une liste non exhaustive de ces outils :

$ ionic start myApp [template]

Cette commande permet de démarrer très vite une application Ionic. Elle vous construira une application en fonction d’un template (celui par défaut, ou bien celui de votre choix parmi les templates proposés). Vous aurez très vite une application fonctionnelle avec laquelle démarrer.

$ ionic serve

Cette commande vous permet de lancer votre application sur votre localhost. Elle sera accessible dans le navigateur de votre ordinateur, mais elle pourra également l’être sur le navigateur de votre Smartphone si celui-ci est connecté au même réseau. Cela permet de tester très rapidement les développements faits.

$ ionic serve –lab

Cette commande fait la même chose que celle décrite ci-dessus, mais en plus elle vous ouvre une page “Lab” dans votre navigateur, à partir de laquelle vous aurez l’aperçu du rendu de votre application mobile sur les 3 plateformes : iOS, Android et Windows Phone.

Capture d’écran 2016-10-10 à 21.42.53

$ ionic build ios/android
Permet de construire le fichier exécutable pour les plateformes iOS ou Android

$ ionic emulate ios/android
Permet de lancer un émulateur afin de tester votre application.

$ ionic run ios/android
Permet de lancer votre application sur un vrai appareil. Si aucun n’est disponible, cela lancera un émulateur.

Pour plus d’informations, c’est par ici : https://ionicframework.com/docs/v2/cli/

Bilan

Ionic est un framework permettant de réaliser de manière très rapide et avec un résultat plus que satisfaisant des applications mobiles hybrides.
Il pourra vous convenir si vous avez besoin de lancer une application mobile très vite sur tous les stores, ou si l’application que vous souhaitez développer ne comprend pas de fonctionnalités très évoluées devant utiliser avec précision les composants natifs des smartphones (c’est-à-dire, si votre application reste une simple application de consultation de données par exemple).

Pour exemple, l’application InTech Mobile a été réalisée avec Ionic 2:
Play Store
App Store

Camille Thomassin, Pierrick Bena et Laurine Schuster

Sources

http://ionicframework.com/
http://ionicframework.com/present-ionic/slides/#/
https://adamdbradley.github.io/building-with-ionic2/#/
http://www.latreebu.com/blog/application-mobile-native-ou-web-3-solutions/

Posted in Non classé | Tagged , , , , | 2 Comments

La vague Modern Agile

L’origine de la vague

Courant 2016 lors d’une keynote à l’Agile Conference d’Atlanta, Joshua Kerievsky, CEO de Industrial Logic (société californienne de conseil en agilité) a fait découvrir à la communauté sa définition d’une agilité plus « moderne »…une agilité qui promet d’inscrire les résultats dans la durée.

Qu’est-ce que c’est ?

Modern Agile se dit «  ultra light » : ni rôle, ni responsabilité, ni pratique particulière. Joshua Kerievsky fait évoluer le Manifeste originel en  4 principes directeurs traduits littéralement et officiellement comme suit:

Modern Agile Wheel

Joshua Kerievsky indique que ces principes sont déjà utilisés par bon nombre d’entreprises internationales (AirBnB, Amazon, Google, Etsy…) mais qu’il n’est pas nécessaire d’être une entreprise de marque pour tirer profit de la « sagesse » du mouvement.

Que se cache-t-il derrière ces 4 principes ?

Principe 1 : Rendre les gens fantastiques

Icon - Make People Awesome« Rendre les gens fantastiques » est la traduction officielle de « Make people awesome »,  et consiste à concevoir et réaliser des applications dans le but explicite d’y impliquer les utilisateurs. La société de développement devrait ainsi transformer ses activités sur base de ce principe.

Amazon, par exemple, suivait un concept similaire nommé « Customer Obsession » démarré en 1997. Et de son côté, Steve Jobs avait l’habitude de demander à ses collaborateurs : « Quels incroyables bénéfices pouvons-nous offrir à nos clients ? Où pouvons-nous emmener nos clients ? ».

« Rendre les gens fantastiques » suggère que nous nous efforcions à rendre tout le monde  « fantastique » dans notre écosystème, c’est-à-dire d’impliquer tous les acteurs  y compris ceux qui créent, réalisent, utilisent, achètent, vendent ou même financent nos produits ou nos services.  L’objectif est d’obtenir un cercle vertueux de gens fantastiques ;o)

Principe 2 : Faire de la sécurité un prérequis

Icon - Make Safety a PrerequisiteJoshua Kerievsky enchaîne sur le deuxième principe en indiquant que « Rendre les gens fantastiques » n’est pas possible tant que  ceux-ci ne sont pas en sécurité. Il indique que, par nature, la sécurité est un besoin humain fondamental, une clé vers la performance.  Ainsi, selon Modern Agile, « Faire de la sécurité un prérequis » met en avant les questions de qualité et de sécurité comme un «ingrédient fondamental de succès».

« Faire de la sécurité un prérequis » signifie d’une part établir la sécurité avant de s’engager dans un travail potentiellement risqué. Pa exemple, dans l’industrie, si la sécurité n’est pas améliorée après chaque accident ou presqu’accident, l’excellence est plus difficile à atteindre.

Joshua Kerievsky adresse également la notion de peur et de blâme à cette réflexion sur la sécurité. Il rappelle que très souvent dans les organisations classiques, la peur de l’échec et surtout du blâme tend à étouffer l’efficacité des équipes. Sous le principe Modern Agile, tout le monde travaille ensemble pour résoudre des problèmes en équipe et cet environnement plus « sûr » conduit à un niveau de qualité globalement supérieur dans la livraison de logiciels.

« Faire de la sécurité une condition préalable » exige que nos collaborateurs, nos produits et nos services soient sécuritaires. Finalement, dans tous nos projets, ne nous efforçons-nous pas de protéger le temps, l’argent, la santé, l’information et les relations humaines ?

Dans un contexte de management, ce principe pourrait également se traduire par « Installer de la confiance et de la bienveillance ».

Principe 3 : Expérimenter et apprendre rapidement

Icon - Experiment and Learn Rapidly« Echouer rapidement et en toute sécurité » a fait partie intégrante du succès de Paul MacCready, père du Gossamer Condor (premier avion à énergie musculaire) et considéré aujourd’hui comme l’un des plus grands ingénieurs du 20ème siècle. Expérimenter et apprendre rapidement est un principe directeur du Modern Agile car il nous protège du gaspillage de temps et nous aide à découvrir le succès plus rapidement. Le concept est de rendre nos expériences « sûres à l’échec » et de cette manière de ne pas avoir peur d’en conduire plus.

« Expérimenter et apprendre rapidement » transforme ainsi l’élimination de la peur de l’échec en un système où l’expérimentation et l’apprentissage sont mis en avant. Cela est particulièrement important compte tenu du rythme rapide de changement dans le monde d’aujourd’hui et de demain. La vitesse est l’essence même de l’expérimentation. Si une expérience ne fonctionne pas, le développeur passe simplement à une autre idée.

Principe 4 : Délivrer de la valeur en continu

Icon - Deliver Value ContinuouslyEn Modern Agile, nous allons nous demander : « Comment pouvons-nous livrer les bonnes fonctionnalités plus rapidement ? ». Pour ce faire, l’approche consiste à mettre en évidence des incréments plus petits pouvant être déployés quasi-instantanément  en toute sécurité.

En effet, livrer de la valeur en continu est un bon moyen pour expérimenter et apprendre rapidement (Principe 3). Dans le développement logiciel, le processus de déploiement sûr et continu permet d’atténuer le stress en rendant la livraison plus simple, presque ennuyeuse et quasi-automatisée. Bien sûr la sécurité complète n’est possible que lorsque vous pouvez effectuer rapidement et simplement des livraisons et des roll-backs.

« Délivrer de la valeur en continu » est ainsi très pertinent pour les entreprises disposant d’un programme de livraison continue. L’accent est alors mis sur la valeur qui est mise à disposition du client aussi rapidement que possible. Et les trois autres principes Modern Agile se combinent pour rendre ce principe final possible.

Conclusion

Pour Joshua Kerievsky, ces 4 principes ont pour but de clarifier nos objectifs et nous guider vers une meilleure gestion des risques, une plus grande efficacité,  une empathie accrue et une réduction du travail pour atteindre un résultat durable.

Une autre interprétation pourrait être la suivante : « Modern Agile a pour objectif de faire grandir les gens. Pour cela, il faut installer confiance et bienveillance, on peut alors expérimenter régulièrement et apprendre vite afin d’apporter de la valeur en continu. » (Eric Siber, dans son article proposant de nouvelles déclinaisons francophones)

Modern Agile reste un concept nouveau et les opinions de la communauté sont variées. Certains pensent qu’il s’agit d’un nouveau buzz word et d’autres l’accueillent comme une bouffée d’oxygène venant booster le mouvement AGILE global.

De mon côté, je constate que les quatre principes énoncés ne sont pas si novateurs. Ils existent et sont approchés le plus souvent de manière isolés. Le fait de les mettre côte à côte permet de mieux comprendre leurs liens et la force que leur mise en œuvre conjointe peut apporter.

Modern Agile, comme Holocracy, Management 3.0 et les autres vagues, décline plus ou moins profondément le Manifeste Agile et ses principes, et tente d’apporter de nouvelles touches à adapter au contexte de chacun. À chaque organisation d’en tirer le meilleur et de garder en mémoire qu’au-delà du « doing Agile » et du nom de la dernière vague, c’est le « being Agile » – l’état d’esprit qui est le plus important !

Posted in Non classé | Leave a comment

Blockchain et gouvernance. Pourquoi un Smart Contract n’est pas un Contrat.

« Code is Law » est l’un des slogans les plus connus pour expliquer le fait qu’une transaction, une fois qu’elle a été exécutée sur une blockchain, ne peut plus être modifiée ni altérée par quiconque et ceci sans le contrôle d’un organe central. Le parallèle est tentant : les programmes écrits pour une blockchain font office de loi car ils s’appliquent automatiquement et les comportements qui y sont décrits sont respectés par construction.

Cette caractéristique des Smart Contracts est en fait vraie pour tout programme informatique : l’ordinateur exécute aveuglément le code en respectant exactement les instructions qu’on lui donne. La propriété supplémentaire des blockchains est que la base de données étant inaltérable, on ne peut pas modifier son état et notamment les « soldes » des comptes en monnaie virtuelle sans l’accord des propriétaires des adresses. C’est cette dernière propriété qui fait qu’en réalité, « Code is Law » est une affirmation fausse du point de vue de la loi telle qu’elle existe dans le droit et qu’un Smart Contract n’est en réalité pas un contrat au sens juridique.

En effet, un Smart Contract est écrit par un développeur (un être humain, en tous cas pour le moment) et exécuté par des machines (l’ensemble des nœuds de la blockchain). Si l’exécution du contrat est infaillible car exactement conforme à ses termes (le code), sa rédaction ne l’est pas. L’aventure de TheDAO cet été en est un exemple flagrant. Le contrat passé entre les investisseurs au sein de TheDAO et les futurs projets comportait au moins une clause dont l’application stricte a conduit au transfert d’environ 40 millions de dollars selon une modalité qui, si elle était possible sur le contrat (sinon elle n’aurait pas pu s’exécuter), n’avait pas été anticipée par les contractants, ni même par les rédacteurs du contrat.

L’article 1128 du code civil français consacre le principe de la volonté des parties concernant la formation du contrat :

  • Les parties ont-elles voulu s’engager ? Il faut vérifier leur consentement.
  • Étaient-elles aptes à le vouloir ? C’est le problème de leur capacité.
  • Qu’ont-elles voulu ? Il faut un objet à leur engagement (art. 1163 du code civil).

Ainsi, avons-nous tous réellement la capacité à contracter un engagement rédigé dans un Smart Contract ? La réponse est évidemment non. Il était possible à tout un chacun de se rendre compte de la faille qui résidait dans le Smart Contract de TheDAO et de voir que cette clause du contrat n’était pas conforme à l’objet de l’engagement, mais une seule personne l’a vue et en a profité.

Le second problème concerne la réversibilité et la possibilité de rompre l’engagement. Une fois le transfert prévu par le Smart Contract mais pas prévu par les contractants effectué, il a été impossible de revenir simplement à la situation antérieure sans contrevenir aux principes fondamentaux de la blockchain. Dans le cas d’un contrat classique, quand il est avéré que l’une des parties n’était pas en capacité de contracter, le contrat est annulé par un tribunal et ses effets annulés également. Le tribunal force la partie qui a tiré profit de la situation à rembourser la partie lésée, par un moyen de saisie si nécessaire. Ceci est impossible sur une blockchain si cela n’a pas été prévu dès la création des « contrats ». Une seconde raison pour laquelle un Smart Contract n’est pas un contrat.

Quelles sont les solutions ?

A court terme, pour qu’un Smart Contract se rapproche d’un contrat, il est nécessaire, d’une part de le faire rédiger, auditer et valider par une personne en capacité de le faire, et d’autre part de permettre la réversibilité des actions exécutées suite à la signature de ce contrat si un organisme autorisé (un tribunal par exemple) en décide ainsi.

Dans le langage des développeurs, nous parlons de « Patterns » à propos de programmes informatiques développés en respectant certains principes définis à l’avance, ou de « Frameworks » quand ces programmes réutilisent du code existant et s’exécutent au sein d’un environnement prédéfini, en en respectant les principes de fonctionnement. Il est nécessaire aujourd’hui que des développeurs et des juristes travaillent main dans la main pour créer des patterns de smart contracts et des frameworks dont la structure et les caractéristiques respectent le droit de la juridiction dans laquelle ils s’appliquent.

Posted in Non classé | Leave a comment

Soyez sans limite grâce à l’IA

Être un super héros de la connaissance

Vous rappelez-vous de cette scène du film Matrix où Néo apprenait le Kung-Fu en quelques minutes ? Réalité ou Science-Fiction ?

neo kung fu

C’est à minima un mythe intéressant. Pouvoir devenir expert en tout et sur tout ! Apprendre toutes les disciplines de votre choix, en un temps record. Et si on vous offrait cette possibilité, que choisiriez-vous ?
Vous vous projetteriez en expert du secteur financier, qui anticipe avec précision les évolutions des marchés à la simple lecture des indicateurs disponibles ? Ou en polyglotte parfait, traduisant à la volée une vingtaine de langues ? Peut-être que votre désir profond est de sauver des vies, comme par exemple le soignant qui détectera précocement tout début de cancer chez ses patients ?

Et si je vous disais que vous pourriez être tous ces champions, à la fois.

Demander conseil à un personne de confiance

L’humanité pratique la mise en commun des connaissances depuis son commencement. C’est ce principe même de regroupement d’individus intégrant une culture commune qui amena le concept de groupes sociaux, de villes et même de civilisations.  Une conséquence importante de ce regroupement est qu’il n’est pas nécessaire de tout connaître personnellement, mais de diviser les connaissances sur plusieurs personnes, chacune se spécialisant dans un domaine particulier. Afin de résoudre une problématique, demander à son réseau permet de récupérer une partie de cette connaissance et de cette expérience, et donc de résoudre le problème comme si nous la possédions nous-même.

La confiance joue un rôle très important dans ce processus. C’est sur base de la confiance que nous choisissons la personne à qui nous allons nous adresser. Mais comment juger de la pertinence de la connaissance d’une personne ? Un expert gagne ainsi souvent sa réputation grâce à la qualité de son travail passé.

Se pose la question suivante : si un ami arrive à prédire la valeur du cours de la bourse du lendemain, sans jamais se tromper, mais que vous ne puissiez pas comprendre son raisonnement, le considéreriez-vous comme quelqu’un digne de confiance ?

Et si cette personne de confiance n’était pas une personne mais reposait sur l’Intelligence Artificielle ? Les évolutions récentes en capacité de calcul, dans les algorithmes de Machine and Deep Learning permettent dès maintenant d’accéder à la connaissance dans de nombreux domaines.

L’aire de l’expertise artificielle

L’intelligence artificielle (IA) est un vaste domaine dont un en particulier ne cesse de battre des records ces derniers temps, celui de « l’Apprentissage Automatisé » ou « Machine Learning ». Les avancées scientifiques et technologiques sont désormais telles qu’on devine l’arrivée d’une singularité technologique, et d’un bouleversement dans l’usage de nos outils informatiques.

Prenons quelques exemples permettant de se rendre compte de ces avancées et des possibilités apportées par l’IA. Intéressons-nous à des applications liées à la médecine, la compréhension du langage, et l’art. Ces domaines sont pourtant, à priori, réservé aux meilleurs experts humains. Ils demandent un croisement de compétences, d’expérience et de capacités cognitives que seuls les humains peuvent détenir.

Domaine médical

Oui, il est désormais possible de détecter les signes de cancer, avec un gain clair en fiabilité de la détection, en utilisant l’Intelligence Artificielle. Le croyez-vous ?

pathAI
Taux de détection de métastase dans les ganglions lymphatiques. PathAI

Un algorithme intelligent permet donc, dès aujourd’hui, de fournir des indices suffisamment fiables du développement de métastases. Une telle conclusion doit cependant être remise en perspective, puisqu’il s’agit uniquement d’un type de cancer précis dans une zone précise du corps. Et si l’IA seule est déjà efficace, le fait de travailler conjointement avec une équipe médicale permet d’atteindre des records de fiabilité. La démarche est ici importante. Ces chercheurs n’ont pas tenté de remplacer l’humain, mais d’intégrer l’IA comme un expert à part entière associé au personnel médical, finalement comme une personne digne de confiance.

PathAI se base sur une technologie appelée « réseaux de neurones convolutionnels » et dont il est quasiment impossible de tirer un raisonnement compréhensible par un humain. Mais les résultats sont là et la technologie digne de confiance, puisqu’elle aura prouvé sa capacité de compréhension sur des milliers de cas passés. De la même manière qu’un expert devenu crédible grâce à la reconnaissance de la qualité de son travail.

Une difficulté intellectuelle intervient alors. Comment faire confiance à ce réseau de neurones dont nous ne pouvons pas appréhender la logique ? Cela reste un raisonnement logique mais qui ne s’apparente plus à la logique humaine.

Domaine linguistique

Nous parlions aussi de devenir un expert linguiste. Microsoft a récemment annoncé la nouvelle suivante sur son blog : «Historic Achievement: Microsoft researchers reach human parity in conversational speech recognition ».

Les réseaux de neurones sont donc désormais capables de retranscrire une information auditive de façon tout aussi fiable qu’un humain. Ils dépassent même très légèrement l’humain. Traduction simultanée, retranscription parfaite, sous-titrage en temps réel pour malentendants, autant de possibilités ouvertes dès aujourd’hui.

Domaine artistique

Comme dans bien d’autres domaines, l’art commence à se révéler comme un des terrains où les machines peuvent nous accompagner. Les machines ne sont pas encore capables de générer de l’art à proprement parler, mais d’autres approches existent.

neural transfer

Exemple de transfert de style basé sur Van Gogh

Soyons franc, un amateur pourrait se laisser berner et penser qu’il s’agit là d’une œuvre originale de Van Gogh. Ceci prouve que l’IA peut désormais comprendre des phénomènes dépassant la simple analyse de données, pour accéder à ce qui paraissait réservé pour de longues années à l’esprit humain.

Le paradigme de l’IA

L’IA amène donc un changement de paradigme. Deux objectifs sont à distinguer.

  1. Chercher à répondre à une problématique sans nécessiter de redéfinir l’état de l’art (donc sans aller plus loin dans la compréhension même des propriétés),
  1. Chercher à créer un nouveau produit ou service qui nécessite une amélioration de l’état de l’art (donc en approfondissant notre perception des propriétés).

Dans le premier cas, concevoir une architecture basée sur des modèles d’IA existants sera souvent bien plus rapide que d’acquérir une véritable expertise dans le domaine et les propriétés qui le caractérise. Un exemple concret réside dans le domaine de la vision par ordinateur (appelé aussi « computer vision ») où concevoir un réseau de neurones permet en quelques jours d’atteindre l’état de l’art des algorithmes classiques. Et pourtant ces algorithmes classiques nécessitent de maitriser parfaitement de nombreux aspects du traitement d’images puis de les implémenter.

Dans le second cas, l’exemple de PathAI est flagrant. Une équipe de deux personnes, dont une n’ayant pas de connaissance dans le domaine médical, a repoussé les limites de la médecine. Microsoft et les géants de l’Internet (Google, Amazon, Facebook…) possèdent également ces capacités et ces technologies promettant une intelligence supérieure à l’humain dans certains domaines de prédilection de l’Homme, comme la communication.

Sommes-nous prêts ?

L’Intelligence Artificielle devient donc cet expert polyvalent, présent à nos côtés comme une capacité latente, prête à vous aider dans vos problèmes quotidiens. Un expert qui s’entraîne et s’améliore grâce à la masse de données s’accumulant dans l’hyper cloud depuis ces 10 dernières années. Un expert qui nous permettra également de deviner, de définir des opportunités nouvelles.

Vous pouvez donc devenir un expert dans le domaine de votre choix. Par quoi commenceriez-vous ?
A moins que la question essentielle soit : êtes-vous prêt à accepter ce nouveau paradigme ?

Posted in Non classé | Leave a comment