Archives pour la catégorie Uncategorized

Développer une DApp Native Android sur Ethereum: Partie 2 – Codage sous Android

Une DApp native est une application native qui interagit avec un Smart Contract déployé sur une BlockChain. Dans le post précédent nous avons défini des principes d’architecture qui permettent d’avoir un niveau acceptable de sécurité et de user experience. Dans cette partie, nous rentrerons dans le code Android qui permet à cette DApp native de fonctionner.

Le code source complet de l’application est disponible sur Github ici : https://github.com/omarbenhamid/android-dareth

Dans ce post nous allons nous concentrer sur les parties du code concernant l’interaction avec la BlockChain. Il peut être utile de consulter le code solidity du Smart Contract pour comprendre certaines opérations.

Présentation générale de l’application

L’application offre 3 fonctionnalités :

  1. La consultation de l’état du smart contract.

  2. L’inscription à un contrat Daret

  3. Le paiement d’une mensualité Daret.

Coté Android il s’agit d’une seule activité qui permet de mener les 3 actions.

Consultation d’un Smart Contract

Comme discuté dans l’article sur les principes d’architecture nous avons choisi d’utiliser l’API JSON RPC Ethereum comme compromis entre utilisabilité et sécurité. La consultation d’attributs de Smart Contract étant gratuite (ne coute pas de gaz), nous n’avons pas besoin d’activer le Wallet.

La sous-classe RefreshInfoTask de MainActivity.java (77) implémente cette interaction.

Nous utilisons la librairie KEthereum pour ne pas ré-implementer les différents protocoles et formats :

1) Il faut initialiser le le client RPC KEthereum :

private static final NetworkDefinition network = new NetworkDefinition3();

private static final EthereumRPC rpc = new EthereumRPC(network.getRpcEndpoints().get(0), new OkHttpClient.Builder().build());

NetworkDefinition3() correspond au testnet Ropsten sur lequel nous avions déployé notre Smart Contract. L’objet rpc ainsi obtenu permet d’appeler les methodes de l’API Ethereum relativement simplement.

2) La BlockChain conserve tout l’historique de tous les états passés d’un contrat dans des blocs. Il faut donc indiquer un numéro de bloc lors de chaque appel pour préciser quelle version nous souhaitons consulter. Voulant le tout dernier état nous allons appeler l’api eth_blockNumber pour récupérer le dernier numéro de bloc (le dernier connu par le noeud Ethereum qui nous fournit le service RPC) :

String blockNumberString = rpc.blockNumber().getResult();

long blockNumber = Long.parseLong(blockNumberString.replaceAll(« 0x », «  »), 16);

Vous noterez que le block number est fourni au format hexadecimal qu’il faut convertir en nombre.

3) Nous allons maintenant récupérer la valeur de l’attribut public moisCourrant du smart contract, cela revient invoquer la methode moisCourrent(). Cette methode est crée automatiquement par le compilateur solidity quand un attribut est marqué public. Pour appeler une methode il faut calculer sa signature : c’est une chaine qui identifie de façon unique cette methode. Le format précis est spécifié dans la documentation solidity mais KEthereum nous permet de le faire simplement:

SignatureFunKt.toHexSignature(new TextMethodSignature(« moisCourrent() »))

4) On utilise cette signature pour appeler l’api eth_call :

StringResultResponse ret = rpc.call(« {\ »to\ »:\ »«  + contractAddr

+ « \ »,\ »data\ »:\ »0x » +

SignatureFunKt.toHexSignature(new TextMethodSignature(« moisCourrent() »))+ « \ »} »,

blockNumberString);

5) Enfin, on convertit le resultat au format numérique en utilisant KEthereum :

moisCourrent = BigIntegerKt.hexToBigInteger(ret.getResult());

De la même manière on récupère les autres informations sur le smart contract.

Execution d’une operation : appel du Wallet

Comme discuté dans l’article sur les principes d’architecture nous allons appeler le Wallet par intent.  Pour ce faire, nous appelons l’action ACTION_VIEW sur une URI Ethereum standard ERC681 qui permet de spécifier une transaction. KEthereum permet de créer ce type d’URIs grâce à la classe ERC681 :

public void onClickInscription(android.view.View v) {

ERC681 tx = new ERC681();

tx.setAddress(contractAddr);

tx.setChainId(network.getChain().getId());

tx.setValue(mensualite);

tx.setFunction(« inscription »);

tx.setGas(new BigInteger(« 50000 »));

startActivityForResult(new Intent(Intent.ACTION_VIEW, Uri.parse(ERC681GeneratorKt.generateURL(tx))), REQ_INSCRIPTION);

}

L’appel android standard startActivityForResult va donc démarrer toute application qui s’est déclarée capabe de gérer ce type d’URI. C’est le cas de WallETH. Assurez vous donc à ce moment là que: 

  1. Vous avez installé la dernière version de WallETH,  car pour pouvoir faire cette appel quelques modifications ont été nécessaires. (Voir ces merge requests pour détail: https://github.com/walleth/walleth/pull/345 et https://github.com/walleth/walleth/pull/347)

  2. Que vous envoyez la transaction sur le testnet Ropsten car c’est celui sur lequel le smart contract est déployé.

Vérifier le succès du paiement

Pour vérifier le succès du paiement, nous allons utiliser l’API BlockScout, ceci dit nous aurions pu faire la même vérification en utilisant le client rpc avec l’api eth_getTransactionByHash.

Dans tous les cas, il nous faut obtenir le hash de la transaction que le Wallet a crée car c’est l’unique identifiant qui permet de retrouver la transaction sur la BlockChain. Il n’y a malheureusement pas de standard pour permettre a un Wallet Android de retransmettre cet identifiant à l’application appelante, le Wallet aue nous utilisons (WallETH) retrourne ce hash dans un extra en réponse sous la clé « TXHASH » . Dans onActivityResult on peut donc le lire :

data.getStringExtra(« TXHASH« )

Vérifier la transaction dans BlockScout revient à appeler en GET l’URL https://blockscout.com/eth/ropsten/api?module=transaction&action=gettxinfo&txhash=TXHASH en remplaçant TXHASH par le hash de transaction. La réponse est un JSON qui contient un objet « result » qui, quand le block est miné, contient un attribut « confirmations ». 

Le code de cet appel / verificiation peut être trouvé dans BlockScoutCheckTransactionTask.java  ligne 65 à 83.

En conclusion

Avec ces éléments nous avons réussi à écrire un application Android qui interagit avec un Smart Contract sur Ethereum. Elle execute à la fois des opérations « gratuites » et des transactions payantes en invoquant le Wallet choisi par l’utilisateur. Il se trouve que notre application ne manipule que des crypto-assets, l’utilisation d’un Smart Contract est donc suffisante pour garantir la sécurité du processus, si ce n’était pas le cas, on aurait eu à plus vérifier les transactions, ce sera peut être le sujet d’un nouveau post.

Développer une Application Blockchain sur Android – Partie 1

Ce poste vient comme suite logique à deux premiers posts pour créer un Smart Contract pour Ethereum et le deployer sur un testnet , je voulais créer une DApp Native : une application sous Android qui permettrait d'utiliser ce contrat de façon intuitive. 

La communauté Ethereum ne tarit pas de tutoriels pour créer des DApp "Web", mais pour les DApp Natives sur Android tous les choix techniques et UX sont à faire. Ce post est dédié à cela.

Revu et actualisé le 27 mars 2018

L'écosystème dans lequel une DApp s'intègre ?

Un DApp se distingue d'une application lambda par le fait qu'elle peut interagir avec un Blockchain, notemment :

  1. Créer des transactions en cryptomonnaie: des transferts simples, des interactions avec des Smart Contracts …

  2. Lire des informations sur des comptes blockchain et des transactions (solde, état d'exécution …).

  3. Accéder aux informations publiées par des Smart Contracts.

Une DApp Native doit pour cela interagir avec :

  1. La blockchain : Réseau qui permet d'accéder aux Smart Contracts, suivre la validation des transactions…

  2. Le Wallet : Application à la quelle l'utilisateur fait confiance pour créer des transactions sur son compte.  

Interagir avec le Wallet

Chaque compte (adresse) dans une blockchain est lié à une clé privée : on peut la représenter comme une séquence de caractères:

8F241D8E4169D4118FD6158BFE81D6158BFE81ADD961ADD961241D8E4169D411

Exemple de clé privée 256 bit

Quiconque connais cette séquences peut exécuter des transactions sur le compte associé. Par exemple : dépenser de la cryptomonnaie.

Le Wallet est l'application, hautement sécurisée, dans laquelle l'utilisateur génère et garde cette clé. Des exemples de Wallet sur Android sont TrustStatus, WallETH … Le Wallet doit signer des transactions avec cette clé pour qu'elles puissent être acceptées sur un blockchain.

On pourrait utiliser une librairie comme KEthereum pour stocker ces clés directement dans une DApp et se passer d'un Wallet séparé, mais cela nuirait à la sécurité et à la user expérience. En effet, cela voudrait dire que l'utilisateur doit faire confiance à notre DApp pour dépenser de la Cryptomonnaie en son nom, ce serait l'équivalent de donner le code PIN de votre carte bancaire à un commerçant. La DApp doit pouvoir interagir avec le Wallet pour faire signer les transactions.

Après étude, j'ai décidé de partir sur le Wallet Open Source WallETH pour deux raisons :

  1. En regardant le code source, j'ai découvert que WallETH propose un Intent Android pour signer les transactions décrites au format ERC681, ce qui est un bon début

  2. Au besoin, il me sera possible d'enrichir cette interface puisque WallETH est Open Source.

Interagir avec la Blockchain

Là aussi, il y a un choix à faire. Il existe en résumé 3 modes pour interagir avec la blockchain :

  • Full Client : Un full client télécharge et maintient une copie complète de la blockchain en local et participe directement au réseau P2P de la blockchain. Pour un client mobile autant oublier tout de suite cette piste : vu la taille et la vitesse à laquelle va le mainnet même un PC de mining a besoin de beaucoup de stockage et de temps pour se synchroniser.

  • Light Client : l'idée est de ne télécharger que les entêtes des blocks pour accélerer la synchronisation. Des libraires comme le package mobile de go-ethereum permettent d'en lancer un sur mobile mais les retours des développeurs restent assez mitigés :

    • Au premier lancement, cela prend parfois à l'application plusieurs minutes pour "se synchroniser" et devenir opérationnelle ce qui n'est pas acceptable de point de vue UX.

    • Même quand l'application n'est pas utilisée, elle doit télécharger les mises d'entêtes de la Blockchain ce qui est nuisible au contraintes de ressources limitées d'un appareil mobile. 

  • Ethereum définit des services standars JSON RPC : certains noeuds Ethereum exposent de tels services qui permettent d'interagir avec la blockchain sans devoir la télécharger en local. beaucoup de Wallets et DApps web semblent utiliser cette approche. 

De point de vue UX l'approche JSON RPC est la meilleure car elle offre une réponse immédiate. De point de vue technique aussi c'est celle qui s'adapte au mieux aux ressources limitées des appareils mobiles. Mais de point de vue sécurité, cette approche rompt avec l'idéal de décentralisation et oblige à faire confiance au fournisseur du service JSON/RPC.

Certaines librairies libres permettent de simplifier l'utilisation des services JSON/RPC sous Android comme Web3J et KEthereum . J'ai choisi la dernière car c'est la même qui est utilisée par WallETH ce qui permet une certaine cohérence. Coté serveur, il est possible de mettre en place son propre serveur JSON/RPC mais il plus rapide et fiable pour un prototype d'utiliser le service en ligne gratuit d'Infura, encore faut-il faire confiance à Infura.

UX Finale Retenue

L'UX finale retenue est donc : 

  1. L'Application crée une transaction : par exemple un payement d'une mensualité sur un Smart Contract Daret et la soumet au Wallet. Sous Android, le mécanisme le plus intuitif serait un Intent.

  2. Le Wallet s'active et demander la confirmation de l'utilisateur, signe avec la clé privée la transaction et la transmet à la Blockchain. Il renvoie alors l'identifiant de transaction à l'application.

  3. L'Application attend alors que la transaction soit validée par la Blockchain en utilisant un service JSON RPC.

  4. L'Application suit le status de la transaction jusqu'à son enregistrement ou son Refus. 

En conclusion

Beaucoup d'options sont possibles pour qu'une application Android interagisse avec une Blockchain, et il n'y a pas encore d'approche standard. Cela est  certainement dû à la complexité des compromis à faire entre sécurité, UX et limitation de ressources des appareils mobiles. De plus le Wallet peut être aussi bien Web ou Mobile, sur le même mobile que la DApp our un mobile différent …

Toujours est-il qu'on a abouti à une UX qui devrait être satisfaisante, ressemblant peu ou proue aux workflows de paiement en ligne. Dans le prochain post de la série, on mettra en oeuvre cette approche sur le cas concrêt sur Smart Contract Daret sur Ethereum .

Deployer un Smart Contract sur Ropsten un testnet d’Ethereum

Dans mon post précédent j'avais exposé les étapes pour développer et tester un Smart Contract du prêt solidaire Daret dans l'IDE REMIX. L'objectif maintenant est de le deployer sur une vraie blockchain. C'était plus facile que je ne croyais.

Les étapes principales seront :

  1. Créer quelques comptes.

  2. Les alimenter en ETH sur une blockchain de test.

  3. Déployer le Smart Contract.

  4. Executer l'inscription, le paiment mensuel et vérifier le bon fonctionnement.

Sur la blockchain Ethereum principale (mainnet) l'ETH  correspond réellement à de l'argent, cela rendrait le test assez coûteux. Heureusement qu'il existe des "testnet" : des blockchain de test ou l'on peut obtenir des ETH gratuitement mais qui ne peuvent bien entendu pas être échagés contre de la devise classique. C'est ce que j'ai utilisé.

Créer des comptes de Blockchain (des adresses)

Pour cela il faut un logiciel spécial (dit wallet). J'installé l'extension de navigateur MetaMask pour cela. 

Pour cela :

  1. J'ai ouvert https://metamask.io

  2. Cliqué sur installer l'extension et fait l'installation.

  3. Un wizard guide pas à pas pour créer un premier compte.

  4. A la fin MetaMask va vous proposer d'alimenter votre compte en ETH sur des places de marché. On n'en a pas besoin pour le test, il suffit de fermer la fenêtre :

 

Par défaut MetaMask se met sur la blockchain principale (mainnet), pour tester, j'ai basculé sur "Ropsten Test Network" grâce au menu en haut à droit de la page MetaMask.

Enfin, pour créé des comptes additionnels il faut cliquer sur "Create account" dans le menu en haut à droite :

Obtenir de l'ETH de test sur les comptes de test :

  1. Il faut aller au le Faucet Ropsten sur https://faucet.ropsten.be/,

  2. MetaMask avait déjà renseigné l'adresse du compte actuellement actif.

  3. J'ai cliqué sur "Send me test ether" et mon premier compte a été alimenté après quelques secondes.

  4. Malheureusement, faucet ne permet d'obtenir qu'un seul ETH par jour. Pour alimenter mes comptes de test j'ai donc transféré 0.2 ETH depuis mon compte principal sur chacun des comptes de test en utilisant le bouton "SEND":

  5. Une astuce tout de même : il suffit de cliquer sur le champs "Recipient Address" pour que MetaMask list les comptes existants : donc pas la peine de copier manuellement les adresses :

Modification du Smart Contract

Dans le le Smart Contract du post précédent la participation était payée en unité d'ETH directement, Il est donc impossible de participer avec 0.2 ETH du coup, j'ai utilisé cette nouvelle version où la contribution mensuelle est en wei (un milliardième de milliardième d'ETH) : https://github.com/omarbenhamid/pret-daret-sur-etherium/blob/c37ed0bb79a79966af15b751eeaabb76a15b7743/daret.sol

Une autre modification est que, dans cette nouvelle version, il n'y a plus besoin d'appeler executerMoisCourrant : dès que toutes les contribution du mois sont reçues, la collecte est envoyée au bénéficiaire du mois, sans action de sa part.

Deploiement et test du Smart Contract:

Le déploiement et test du smart contract se fait exactement comme l'exemple précédent sauf :

  1. Il faut recharger Remix (actualiser la page dans le Browser pour reconnaitre metamask)

  2. Dans l'onglet Run choisir le runtime "injected by Web 3":

  3. Charger le code du Smart Contract dans le fichier daret.sol dans REMIX, comme décrit dans le post précédent.

  4. Ensuite saisir les paramètres et cliquer sur deployer :

    Noter le 2 suivi de 15 zeros qui correspond 2/1000 d'ETH (= 2 finney en langage ethereum), en effet le "wei" est une très très petite unité. Suivi de d'une virgule suivi de 3 qui est le deuxième paramètre du constructeur du contract qui dit : Daret se déclanche dès qu'il y a 3 participants.

  5. Une fenêtre MetaMask va apparaître, il faut y confirmer la transaction

  6. Sur MetaMask ou dans les traces Remix: attendez que la transaction soit validée.

Bravo ! Le smart contrat est déployée sur une vraie blockchain.

Executer les tests

En mode connecté à la blockchain, Remix fonctionne comme en mode normal sauf 2 points:

Le premier est que REMIX ne propose dans l'onglet Run qu'un seul compte : le compte actif dans MetaMask. Pour basculer entre les différents comptes il faut donc :

  1. Ouvrir MetaMask.

  2. Choisir le compte souhaité dans le menu en haut à droite:

  3. Revenir dans REMIX. Vous verrez alors que c'est le noveau compte qui est devenu actif.

Le second est que vous aurez la fenêtre de confirmation MetaMask à chaque transaction qui s'affichera pour confirmer.

À ceci près, j'ai pu rejouer les tests comme cela a été fait dans le post précédent en utilisant 2 finney au lieur de 1ETH pour chaque contribution.

En conclusion

C'était relativement faclie de déployer et utiliser le Smart Contract Daret sur le testnet Ropsten. L'étape suivante est donc de développer une DApp: une application érgonomique pour utiliser ce Smart Contract. A suivre donc …

Pas à pas : créer un Smart Contract pour la blockchain Etherium

On dit que les cryptomonnaies pourraient rendre service aux non bancarisés, du coups pour des premiers pas sur la blockchain j'ai implémente en Smart Contract pour Daret, un prêt solidaire qui se base sur un principe simple : chaque participant paye une somme fixe chaque mois, et, à tour de rôle, chacun parmi les participants reçois la somme totale collectée pendant le mois.

Entrée sur la blockchain Etherium:

Pour utiliser une cryptomonnaie on doit installer une application Wallet (porte monnaie électronique). Dans ce Wallet on génère une adresse (sorte de numero de compte) qui pourra recevoir et envoyer de l'"argent". C'est à la fin comme le E-Banking de votre banque: on a des comptes, un solde, on peut réaliser des transferts … sauf qu'il n'y a pas de banque derrière.

 

Enfin, le "compte" (adresse) Etherium n'est pas disponible en EUR ou en MAD mais en une "devise spéciale" : l'ETH (ether). Pour l'alimenter il faudra donc échanger de la monnaie locale contre de l'ETH. A priori ça se fait bien sur des Marketplace sur internet mais je regarderai ça quand j'en serai là. 

Daret sur Etherium

Pour mettre en place notre Daret on va supposer que chaque participant a installé un Wallet et a donc une adresse avec quelques ETH. Il faut alors écrire un Smart Contract qui recevra chaque mois les contributions de chacun et transférera la somme à la bonne personne selon l'ordre défini.

Vous avez dit Smart Contract  ?

Avec première vue avec un oeuil de POO, j'ai l'impression que créer un Smart Contrat revient à définir une classe (avec attributs et methodes donc) et l'instancier "dans" la blockchain. A la différence d'un "new" qui instancie en mémoire est que une instance de cette classe sur la blockchain ne peut plus être contrôlée par personne : Elle "vit" sa vie sur la blockchain, et les seules interactions possibles sont les appels de methode et la lecture de ses attributs publics. On ne peut même pas la mettre à jour, la detruire ou en faire quoi que ce soit.

Cela se fait dans un langage spécial appelé Solidity. Voila mon Smart Contract Daret :

(Source récupérable sur mon github : https://github.com/omarbenhamid/pret-daret-sur-etherium/blob/2e7baa232463491cb12fb37a28ec19579404a357/daret.sol)

Je ne vais pas commenter plus, les adeptes de POO reonnaîtront la structure de classe à ceci près que ça s'appelle "contract" et non classe.

Utiliser le Smart Contract 

Pour le faire professionnellement, il y a tout un SDK pour compiler, tester et instancier (déployer) ce Smart Contract sur la blockchain, mais pour les premier pas, ce tutoriel très intéressant m'a fait découvrir : Remix, L'IDE 100% en ligne d'Etherium ou j'ai pu en quelques clics tester mon Smart Contract.

Donc sur https://remix.ethereum.org/

  1. J'ai cliqué sur le petit "plus" pour créer daret.sol

  2. Mis le contenu du Smart Contract dans la fenêtre centrale. 

  3. Choisi la version (0.4.25 pour moi).

Ensuite, c'est extrêmement simple d'"instancier" (ie. Deployer) ce contrat :

  1. J'ai cliqué sur l'onglet "run"

  2. Un champs me demande uint256_mensulaiteEther (ce qui correspond au paramètre de mon constructeur) j'ai donc choisi 2 ether par mois comme contribution par participant.

  3. J'ai enfin cliqué Deploy.

Quasi immédiatement, un bloc est apparu en bas de la page me permettant d'appeler les méthodes du contrat et d'en consulter les attributs.

 

Première interaction avec le Smart Contract

Avant d'utiliser notre Smart Contract notons 3 choses :

  1. On est en train d'utiliser l'environnement de test JavaScript VM : le smart contract ne va pas vraiment sur une blockchain, c'est juste une simulation. Remix offre d'autres choix qui devrais certainement me permettre de déployer ailleurs … on verra.

  2. Remix offre dans cet environnement des "comptes" de test : le numéro commançant par 0xca3… est l'adresse (en quelque sorte votre IBAN sur la blockchain). Chaque compte compte au départ 100 ether.

  3. Bonne nouvelle, cliquer sur le petit (+) permet d'ajouter autant de comptes que vous voulez pour vos tests. Si vous voulez tester avec 4 participants par exemple, vous pourrez créer 4 comptes.

On va maintenant tenter une inscription. Vous verrez dans le compte de la "methode" inscription() qu'il est exigé que "msg.value == mensualite", "msg.value" est la quantité d'ETH que l'utilisateur a envoyer au contrat en appelant la methode. On exige en effet qu'à l'inscription le participant paye le premier mois.

J'ai donc tenté de m'inscrire :

  1. J'ai choisi un compte.

  2. Saisi une valeur de 2 (et bien choisi l'unité ether).

  3. Puis cliqué sur "inscription"

Visiblement, ça a marché ! j'ai eu une coche verte dans les logs 

Quand il y a une erreur, c'est plutôt la croix rouge qui apparaît.

Pour contrôler que je me suis bien inscrit, j'ai aussi lu la cellule 0 du tableau "particpants" :

  1. J'ai donc cliqué sur "participants"

  2. Saisi un index (0 par exemple pour lire le premier du tableau)

  3. Cliqué sur "call"

Et l'adresse retournée correspond bien à l'adresse qui s'est inscrite.

Je ne vais pas détailler la suite, mais globalement j'ai :

  1. Appelé inscription() 4 fois avec 4 adresses différentes.

  2. Cliqué sur executerMoisCourrent() : le premier participant a reçu la somme collectée.

  3. Applé payer() en envoyant 2 ETH par participant, puis executerMoisCourrent() : le second participant a reçu 8 ETH …

  4. J'ai bien testé aussi : si un participant ne paye pas, executerMoisCourrent() échoue.

Une note sur le gas

Vous noterez qu'à chaque fois que vous faite une transaction le compte actif perd quelques pouillèmes d'ETH, c'est le coût que vont recevoir les ordinateurs connectés à la blockchain qui vont exécuter le code de l'appel demandé et valider la transaction (une sorte de coût de hosting). Ce temps de calcul est comptabilisé en "gas" et chaque unité de "gas" coute quelques wei (un wei est un milliardième de milliardième d'ETH).

Pour finir ?

J'ai aussi tout de même découvert que, quand executerMoisCourent() échoue le Smart Contract n'explique jamais pourquoi, il faut probablement ajouter une méthode pour expliquer l'échec, lister les impayés …. Bien entendu, tout lecteur de ce post est appelé à forker et améliorer ce contrat sur github : https://github.com/omarbenhamid/pret-daret-sur-etherium

La suite serait de réellement déployer sur un testnet (une blockchain de test), puis de développer une DApp : une appli conviviale qui permet d'utiliser ce contrat.

Mais au bout du compte, la question reste ouverte : Croyez-vous vraiment que la blockchain peut servir aux non-bancarisés ?

Elements d’un projet EMS

Un projet EMS est d’abord un projet informatique, il convient donc de respecter pour ce type de projets les démarches et jalons classiques du recueil des besoins à la recette. Ceci dit, au vu de l’architecture et de la nature d’un EMS, ces quelques lignes attirent l’attention sur quelques spécificités des projets EMS auquelles il est important de faire attention.

Les éléments d’un projet EMS

L’étude d’un projet EMS doit prendre en compte :

  • La mise en place des appareils et équipements intelligents pour remonter l’information.

  • L’eventuel interfaçage avec l’existant.

  • La fourniture des contrôleurs locaux, leure installation et leure maintenance.

  • La mise à disposition du serveur central:

    • Soit la fourniture, installation et maintenance sur l’intranet de l’entreprise.

    • Soit l’abonnement pour l’accès au serveur central sur le cloud.

  • La connexion réseau pour accéder au serveur central ou internet si le serveur central est chez le fournissuer EMS.

  • La connexion locale entre appareils intelligents et les controlleurs locaux (installation du réseau filaire ou sans fil, étude de la qualité du courant porteur …).

Les risques projet spécifiques à l’EMS

Tout d’abord, il faut analyser l’impact sur la continuité d’activité, surtoût quand le système ne fait pas que de la collecte passive d’information  :

  • Que se passe-t-il si le serveur central ne répond plus ou en cas de coupure de connexion? 

  • Que se passe-t-il si le controlleur local est en panne ?

Dans ces deux cas, il faut s’assurer que l’on peut continuer à travailler même si l’utilisation de l’énergie n’est pas optimisée. Un mode dégradé « hors connexion » doit donc être en place.

Ensuite il faut penser à la réversibilité : à quel point mon activité devient dépendante du fournisseur, quel impact si le fournisseur venait à arrêter son offre :

  • Pourrais-je continuer à travailler? 

  • L’offre est-elle assez ouverte pour basculer chez un autre ? 

  • Que dois-je refaire dans ce cas ? Juste le serveur central  ? Rempalcer les contrôleurs ? Racheter aussi tous les capteurs mis en place ?

La réversibilité mérite d’être étudiée non seulement pour maîtriser le risque d’arrêt d’activité du fournisseur mais surtoût pour éviter trop de dépendance vis à vis du fournisseur. Il faut en effet privilégier les offres ouvertes et se méfier des offres intentionellement « opaques ».

Enfin il y a le risque de sécurité :

  • Sécurité des données: quand les données sont remontées sur le serveur du fournisseur. Si les données sont sensibles, s’assurer qu’elles sont stockées et utilisées dans de bonnes conditions.

  • Sécurité physique: la possibilité que le système soit piraté et quel impact cela a. Il faut donc s’assurer que les protocoles d’échange sont sécurisés et authentifiés et s’assurer que le fournisseur propose aussi, dans le cadre de sa maintenance la mise à jour des composants (surtout les contrôleurs locaux) pour corriger les failles de sécurité.

Architecture technique d’un Système EMS

L'objectif d'un EMS est d'optimiser l'utilisation d'énergie de systèmes phyisques, un EMS est donc toujours une brique logicielle qui doit interagir avec le monde réel pour former un  "cyber-phyisical-system". Dans ce type de systèmes l'interaction entre le logique et physique se fait à travers deux types d'interfaces : les capteurs et les actuateurs. Les premiers remontent une information (ex. consommation instantannée d'énergie) à partir d'un objet physique vers un programme, Les seconds appliquent physiquement les consignes d'un programme (ex. arrêter / mettre en marche un climatiseur).

Les capteurs et actuateurs sont déployés directements à l'endroit ou le processus phyisque se produit. Pour permettre une contrôle centralisé, les capteurs vont remonter l'information jusqu'à un système central qui va collecter, croiser et analyser les informations, calculer un fonctionnement optimal et renvoyer aux actuateurs des commandes pour optimiser le fonctionnement. 

EMS une application Internet of Things

 

Plusieurs approches sont possibles pour ce type de systèmes, les plus modèrnes vont se baser sur une architecture IoT (internet of things). La gestion des données se fait alors sur le cloud et l'échange de données avec le système central passe par le réseau IP: internet ou intranet.

Concrêtement, il un serveur central doit être installé soit sur le site de l'entreprise soit sur le site du fournisseur (dans le cloud) et sur le terrain : 

  • soit des appareils intelligents, capables d'échanger des informations et des commandes avec le cloud (machines industrielle, équipement "nativement" intelligent, smartphones …)

  • soit des "add-on" permettant d'observer et contrôler les appareils existants. Les plus simples étant par exemple les prises et interrupteurs connectés et les compteurs intélligents.

  • soit, des postes de saisie (un smartphone par exemple). Un opérateur relève alors les informations terrain et reçois les instructions via ce poste.

Optimisation de coût et performace

Dana les systèmes IoT, il est possible que l'appareil intélligent se connecte directement au serveur, mais il s'agit d'un cas très rare : l'électronique pour se connecter à internet coute cher, sans compter l'éventuel abonnement internet sans fil et les risques de sécurité. La reference est donc la mise en place d'un controllereur local (edge controller). Il s'agit d'un boitier, installé sur site, connecté à internet pour échanger avec le serveur central et connecté aux appareils intelligents par des connexions moins coûteuses (blutooth, zigbee, courant porteur …). Ce boitier est en général fourni par le fournisseur de solution EMS et fonctionne en boite noire : l'entreprise n'a pas besoin de l'administrer. Dans des déploiement très larges, plusieurs controlleurs locaux sont mis en place. Parfois, une simple application sur une tablette ou smartphone peut jouer ce rôle.

L'edge-controller permet aussi de jouer plus actif dans un système de contrôle hierarchique, mais le besoin d'une telle fonction est rare pour les applications EMS. 

Et le SCADA ?

Le SCADA (ou Supervisory Control And Data Acquision) est un système qui s'est développé à partir des années 60 et qui a permis, avec les moyens de l'époque, de superviser et contrôler de façons centralisée des usines, des infrastructures, et plus tard, des batiments. Le SCADA a l'avantage et les défauts du "first-mover" : il est en effet  largement déployé, fiable et mature mais en même temps pas assez ouvert: les systèmes SCADA ne sont pas faciles à intégrer avec d'autres applications. 

On pourrait techniquement créer un EMS autour d'un SCADA, mais il y a tellement d'écarts entre les deux types de systèmes qu'il faut bien étudier avant de faire ce choix. Il faut notamment penser à :

  • L'historisation des données : Il faudrait mettre en place une historisation à long terme des données: un EMS doit permettre une analyse sur le long terme, le SCADA est d'abord conçu pour superviser et contrôler en temps réel. 

  • Les IHM d'analyse : les IHM SCADA ne sont pas construites pour de l'analyse à long terme, il faut donc prévoir la construction d'IHM spécifiques permettant d'exploiter les données historiques.

  • Généraliser l'accès aux données : Il faut aussi prendre en compte qu'un logiciel EMS n'est pas sensé être exploité uniquement depuis un "centre de contrôle" mais partout en entreprise : la direction financière pour contrôler ses factures, la direction technique pour détecter les dérives techniques, et tous les employés en général pour adopter un comportement moins énergivore.

  • Étendre le déploiement SCADA : un SCADA n'étant pas déployé pour optimiser l'utilisation de l'énergie, il faut aussi à des niveau plus bas ajouter de nouveaux capteurs et contrôleurs et les interfacer avec le SCADA pour remonter la bonne information, d'autant plus la gestion d'énergie ne concerne pas que l'usine mais tout les points de consommation y compris les bureaux, les entrepôts …

Construire un EMS basé sur SCADA serait techniquement possible mais il nécessite un effort de développement tel qu'il est souvent plus judicieux d'utiliser un EMS conçu autour d'une architecutre IoT et éventuellement l'interfacer avec le SCADA existant.

Recrutement et rétention d’éducateurs en milieu rural

La qualité de l'enseignant est considérée comme un élément clé de la réussite scolaire des élèves, or recruter et retenir des éducateurs de qualité dans les milieux ruraux victimes d'éloignement et de pauvreté est un challenge. L'objet de ce billet est de synthétiser des éléments de la littérature académique abordant les difficultés de recrutement et de rétention d'éducateurs en milieu rural. Afin de se faire une idée plus claire de l'ampleur du défi et partager des expériences pour inspirer une action et des choix efficaces. 

Différentes études relatent des difficultés auxquelles font face les éducateurs en milieu rural (Sargent & Hannum, 2005) (Collins,1999) (Howley & Howley, B., 2005). Elles peuvent aussi bien être d'ordre professionnel mais aussi personnel et social, elles sont liées à :

  1. L'éloignement de leur lieu d'origine 
  2. La situation de l'enseignant: le fait d'être plus jeune, d'être male, d'être célibataire, d'être plus qualifié réduisent la satisfaction des éducteurs en milieu rural.
  3. L'isolation, et le manque d'interaction avec les collègues, accentuée par le décalage culturel avec la communauté locale (Sargent & Hannum, 2005) et le manque de moyens de transport et de communications (Sargent & Hannum, 2005)(Howley & Howley, B., 2005)
  4. La charge de travail, typiquement dans le cas de classes multi-niveau, surtout dans les cas ou des préparations ou taches spécifiques doivent être réalisées hors temps scolaires.
  5. La question du salaire est un grand élément d'insatisfaction qui est accentué en milieu rural par le coût élevé de la vie et par le manque d'opportunité de travail complémentaire comme les cours de soutien.
  6. Manque de moyens et de ressources de l'école.
  7. Difficulté de trouver un compagnon pour les célibataires.

Il ressort de la revue de littérature que ces difficultés sont rencontrées aussi bien dans les pays en développement que dans les pays développés, bien que l'acuité des problèmes diffère d'un milieu à l'autre. Ainsi, dans les pays en développement, le problème peut être accentué par une vie rurale plus dure, mais dans les payes développés un défi supplémentaire provient de l'abondance d'opportunités plus intéressantes en ville.

En contre partie, certains éléments positifs du travail en milieux rural que les éducateurs apprécient sont selon (Collins,1999):

  1. Meilleur dicipline des enfants 
  2. Plus de liberté de décision et d'action de l'éducateur, notamment la prise en compte de ses remarques, retours dans le choix de l'école sont importants. 
  3. Taille de classe plus petite (le cas échéant) 
  4. Charge réduite de travail (le cas échéant) 

En plus de ces points, des points plus généraux comme les opportunités de développement professionnel, de formation, La proximité du village d'origine  … sont importants.

(Collins,1999) indique que l'une des approches intéressantes pour recruter et retenir les enseignants dans ces milieux ruraux est le "grow-your-own", c'est à dire encourager les étudiants de communautés rurales à devenir enseignant dans leur propre village. Le travail commence alors au niveau du lycée par identifier les candidats ayant les bonnes compétences pour les motiver à envisager une carrière d'enseignant rural. Ainsi le club "Future Teachers America" encourrage les jeunes étudiants à envisager un carrière d'enseignant dans leur village natal après leur diplôme.

Afin d'encourrager les enseignants à s'installer dans le milieu rurale, des incentives importantes sont mises en place, comme :

  1. Primes et avantages salariaux  (Argentine : 80% du salaire de base, Nepal : 100% du salaire de base, Philippine : 25%, en Costa Rica, Egypte, Guyane, Honduras, Jamaique, Lybie,  Mexique, Venezuella)
  2. Formation spécifique (Bangladesh, Colombie, Mexique, Nicaragua, Venezuella)
  3. Avantage sur les retraites (Costa Rica)
  4. Avantages sur la carrière : Accélération de l'avancement, choix d'affectation … (Egypte, Guyane, Honduras)
  5. Logement offert, accès à la propriété (Iraq, Mexique, Pakistan: foyer pour femmes, Sierra Leone, Senegal, Syrie, Zimbabwe )
  6. Création de réseaux d'enseignants et opportunités de rencontre et échange (Mali et autres).

Selon (Howley & Howley, B., 2005), bien que certaines de ces mesures soient bien conçues en réponse à des besoins identifiés des éducateurs et en fonction des contextes des pays, l'efficacité de ces mesures reste fondée sur des hypothèses théoriques sur le comportement et les priorités de l'éducateur qui ne sont pas prouvées empiriquement. 

D'autres pays, en prise avec ces difficultés ont aussi recours à des stratégies différentes comme :

  1. Le recrutement d'enseignants locaux même moins qualifiés (Sargent & Hannum, 2005)
  2. Une prime par élève pour les initiatives d'écoles privées rurales (Collins,1999), il peut s'agir de jeunes femmes du village qui enseignent,  des fois chez elles, quelques enfants pour une somme modique.

Au delà de ces mesures, il semble selon (Collins,1999) qu'une forte implication dans la vie scolaire et culturelle de la communauté cible contribue à augmenter les chances de rester. Certains enseignants de milieu rural peuvent aussi maintenir une double activité d'enseignement et de travail de la terre. Même si l'expérience peut être éprouvante, leur niveau d'éducation leur permet de s'améliorer dans leur pratique.

En synthèses, les difficultés rencontrées par les enseignants en milieu rural sont réelles et multiples, ce qui rend leur recrutement et rétention plus délicats. En réponse à ses difficultés des approches d'encouragement tout aussi diverses ont été mises en place, aussi bien que des approches d'accompagnement à plus long terme pour développer au sein de la communauté même la ressource à même de prendre en charge la mission d'enseignement. Pour la suite, cette revue demande certainement à être complétée par une revue des études empiriques sur l'efficacité des différentes approches.

Lecture dans « Hooked » : La démarche pour rendre accros des Appli Smartphone

La psychologie de la dépendance, appliquée aux Applis

Être "accroc" a son téléphone est ce qui nous prend des fois quand nous ouvrons spontanément nos téléphones pour y passer plusieurs minutes sans avoir d'objectif précis ou savoir pourquoi. Ou comme dit l'auteur, c'est ce qui conduit certains à regarder leur Smartphone le matin avant de dire bonjour à leurs bien-aimés.

Réussir à mettre l'utilisateur dans cet état est pour les éditeurs d'application un Graal procurant divers avantages dont la fidélité et la propension plus élevée à payer des services. Ce livre analyse cet état de dépendance vis à vis des applications en faisant référence à des recherches en psychologie, ethnologie … pour aller chercher au plus profond de la psychologie humaine et de ses prédispositions génétiques comment le rendre accroc.

Se voulant comme guide pour les Startup Technologiques, le livre définit et détaille un modèle simple appelé le "Hook Model" (Le modèle du crochet ou de l'hameçon)  qui est un cycle d'activité sensé faire naitre le comportement Accroc chez l'utilisateur. Il montre ainsi plusieurs exemple sur comment 7des applications et des jeux vidéos sont conçus pour rendre accroc et comment nous tombons dans le piège. Reconnaissant que ll'approche est à limite entre le Design et la Manipulation, l'auteur propose une chapitre pour pour réfléchir sur l'éthique de la démarche.

Ce livre peut se lire sous l'angle d'apprendre comment concevoir des applications Smartphone qui rendent accroc, mais il est plus riche à lire sous un autre angle : Celui de mieux nous connaitre et connaître comment, inconsciemment, nous interagissons avec la technologies et nous développons de nouvelles habitudes. A nous d'en faire des habitudes positives ou négatives. 

Le Modèle de l'Hameçon (Hook Model)

Naturellement, certains déclencheurs provoquent des réactions de notre part : Quand le téléphone sonne nous régissons en répondant à l'appel. Ce genre de déclancheurs sont appelés des déclencheurs externes  (external Triggers). 

Les entreprises qui souhaitent rendre une application addictive cherchent à associer l'utilisation de leur application à déclancheurs internes, souvent inconsients. Par exemple:

Crainte d'oublier une tache ou une idée    
Noter dans Evernote  
Peur de laisser fuir l'instant présent 
Prendre une photo instagram
Besoin de lien social
Ouvrir facebook

Le modèle de l'hameçon est un cycle en 4 etapes qu'une application va faire parcourir à l'utilisateur un certain nombre de fois pour associer le déclencheur interne voulu à l'utilisation de l'application, comme une sorte d'entrainement  C'est étapes sont : 

  1. Tout d'abord le déclencheur qui est en un premier temps externe : sonnerie, reception d'e-mail … Le but étant qu'il devienne interne à un moment. Le livre donne l'exemple de cette application de gestion de tâches qui détecte les réuni nos de l'utilisateur dans son agenda. Elle lui envoie, en fin de réunion un message pour lui proposer de notre ses idées et tâches. Pourquoi ? Parce que, en fin d'une réunion riche on sent le besoin d'organiser des tâches et des idées, avec une crainte de rater des points importants. C'est cette émotion que l'éditeur de l:'application veut connecter à son application. Au bout d'un certain nombre de répétition l'utilisateur sera conditionné à ouvrir l'application à chaque fois qu'il se sent confus.

  2. Ensuite viens le temps de l'action.

  3. Ensuite l'action donne lieu à une récompense (Reward ). Cette partie se base sur les études menées en neurologie et psychologie sur l'addiction, notamment aux jeux d'argent. En résumé. Ce qui provoque l'efusion d'hormones du plaisir dans le cerveau n'est pas l'obtention d'un objet désiré mais l'attente impatiente de cet objet. Provoquer de façon reccurente une telle sensation crée un comportement addictif. Si l'action donnait lieu en permanence à la même récompense, l'utilisateur s'habitue et n'a plus cette attente de la récompense. Par contre il suffit que cette récompense soit rendue aléatoire pour que le comportement addictif commence à se mettre en place. Par exemple :  quand on ouvre sa boîte mail on ne sait pas combien de nouveaux mails on a, qui nous a écrit . ..

  4. Ensuite vientviens la phase d'investissement

Pour boucler la boucle un nouveau déclencheur doit amener l'utilisateur refaire un cycle action/recompense/investissement . 

Introduction à Running Lean : une méthode pour lancer sa Startup

Il existe plusieurs guides du type « comment faire une étude de marché », pour les Startups ces méthodes sont inadaptées et se transforment rapidement en méthode pour produire de la paprasse pour faire plaisir aux partenaires et investisseurs.
Les méthodes du Lean Startup et Running Lean en particulier se positionnent à l’opposé : c’est des démarches spécifiquement adaptées aux Startups conscientes que leur existence se justifie principalement par leur capacité à apporter des réponses pertinentes à des problèmes que vivent leurs clients.

Running Lean

Basée sur les pratiques du Lean Startup, la méthode Running Lean a été inventée et développée par Ash Maurya. Alors que les méthodes d’étude de marché pré-supposent que le produit est déjà défini, Running Lean met les entrepreneurs dans une démarche d’apprentissage qui développe leur produit en parallèle du développement de leur connaissance du marché.

Le challenge d’une startup

Le succès selon Running Lean est de :

« Réussir à trouver un business qui fonctionne avant d’épuiser ses ressource »

Or l’e-commerce existait bien avant Amazon, le webmail bien avant Gmail et les réseaux sociaux bien avant Facebook ce n’est donc ni la technologie ni l’idée qui fait le succès d’une startup mais autre chose.
Appliquer Running Lean commence donc par se rendre compte de cette réalité et de se mettre à la recherche de ce « business qui fonctionne ».

Tout entrepreneur honnête est dès le départ convaincu qu’il a une bonne solution, avantageuse pour ses utilisateurs, mais ceci n’est malheureusement pas la condition d’un « business qui fonctionne ». La condition d’un « business qui fonctionne » est que suffisamment d’utilisateurs soient prêts à payer un prix convenable pour la solution proposée, cela nécessite que la solution résolve un problème qui « compte » pour l’utilisateur. D’ou la première Phase du développement d’une startup : le Problem / Solution fit.

Les phases de développement d’une startup selon Running Lean

La vie d’une Startup est découpée en 3 phases, à chaque phase l’entrepreneur concentre ses efforts sur un aspect différent de son entreprise :

  • Phase 1, « Problem/Solution fit » : La correspondance entre la solution qu’on souhaite apporter et les problèmes que vivent les clients supposés : est-ce que ce qu’on propose permet aux utilisateurs de résoudre un problème qui compte pour eux ?
  • Phase 2, « Product/Market fit » : La correspondance entre le produit et le marché : mes clients sont il prêts à utiliser ma solution dans des conditions financières acceptables pour moi ?. Lors de cette phase on cherche notamment à découvrir à quel point les utilisateurs sont prêts à payer un prix pour la solution.
  • Phase 3, « Scaling »: Le développement, c’est à dire mettre en place le nécessaire pour « vendre la solution en masse ».

Par exemple : Les méthodes d’étude de marché se concentrent sur des études quantitatives. Pour Running Lean, cette activité n’est pertinente qu’en fin de Phase 2 et en préparation de la Phase 3: il est trop risqué d’investir du temps et de l’argent sur des études de ce type avant d’avoir muri la reflexion sur la pertinence de sa solution et la viabilité de son produit.

La démarche d’apprentissage continu

80% des produits nouveaux échouent. Running Lean se base donc sur le principe que l’on va forcement se tromper au départ, de fait « quit a se tromper, autant se tromper les plutôt possible ». Aussi une démarche concrète de test est systématiquement présente à chaque étape :

  1. On écrit ses idées et hypothèses (en moins de 20 minutes en général)
  2. On identifie parmi ces point ce qui est flou ou simple supposition.
  3. On met en place le nécessaire pour le tester.
  4. On reboucle sur l’étape 1.

Pour permettre de rapidement décrire les aspects clé des idées de produit, Ash Maurya a conçu un tableau dérivé du Business Model Canvas qu’il a appelé Lean Canvas. Sur le lean canvas les aspects aussi bien stratégiques, techniques que commerciaux sont notés et en fonction de la Phase de développement de la startup, les tests se concentrerons certaines cases plutôt que d’autres.

Un avis sur la méthode

Il ne faut pas se tromper : le succès ne dépends pas d’une méthode, aussi rigoureux soit-on à l’appliquer, en contre partie, le succès se donne rarement à ceux qui ne se remettent pas en question et qui ne se mettent pas en posture d’apprendre de l’expérience des autres. Donc comme toujours : il faut lire le livre, il y a des choses intéressantes, se retrousser les manches, et tracer son propre chemin.

Au Startup Weekend HEC du 2 Mai : ça vaut le coups d’être Startuper « technique »

Le concept est génial, l’ambiance aussi, le slogan : « Not Talks Just Action » est bien appliqué, de l’excellent team-building, reste la motivation pour poursuivre ….

En pratique, c’est un weekend ou on sélectionne le vendredi soir des idées. Puis on forme des équipes qui, accompagnées par des coachs, vont travailler le long du weekend et présenter le dimanche soir devant un jury d’entrepreneurs et d’investisseurs.

C’est un excellent moyen de travailler avec une équipe pendant un week-end pour non pas connaitre les ‘CV des gens’ mais bien voir l’équipe et les personnalités fonctionnent bien ensemble. Ceci dit, pour le coups.

Un point d’étonnement tout de même, pour quelq’un issu d’un milieu « technique » : les personnes capables de mettre en oeuvre, techniquement, les innovations imaginées (dits développeurs dans le StartupWeekend) sont rares et recherchées, contrairement à ce qu’on peut s’imaginer !

Une dernière note : en fin de partie, les projets qui ont eu les meilleures places du jury ont finalement été des projets portés par des « développeurs » et qui avaient un certain avancement technique concrêt … à méditer …