RESTClient : l’outil de test qui révolutionne la relation Client-Editeur

Réponse "OK" sur l'appel d'un web service

Réponse « OK » sur l’appel d’un web service

Quand vous réalisez une application mobile, il y a deux composantes : l’émission et la réception des données. Ces dernières sont régulièrement associées à deux acteurs : le Client commanditaire de l’app, et l’Editeur de l’app. Il est nécessaire que les rôles techniques soient clairement définis, sinon cela pourrait ralentir le projet et créer des tensions inutiles.

Il existe des outils dédiés à cela, très faciles d’utilisation, gratuits, et en ligne.

A qui est destiné cet outil ?

1/ Au manager

Le manager pourra constater de manière tangible ce qui sort de son SI. Sans se soucier du chaînon en aval, il testera les données brutes.
Il testera par exemple que les caractéristiques produit sont bien celles attendues, avant de passer le prisme de l’application mobile.

2/ Au développeur

Côté Emission de données / Client : le développeur mettra sur pied un « export » contenant tous les flux exposés : à partir du moment où tout est conforme sur l’outil, il aura fait son travail, ni plus ni moins.

Côté Réception /Editeur : le développeur pourra quant à lui « consommer » les flux de manière sereine ; il aura un objectif simple, reproduire ce que fait l’outil, sans se soucier du paramétrage et surtout sans dialogue inutile avec le Client.

3/ Au testeur

Dans le cadre de la gestion de la disponibilité des flux, l’administrateur pourra vérifier continuellement son bon fonctionnement. Il pourra s’essayer avec différents jeux de données, et vérifier que les codes de retour sont ceux attendus.

Quand utiliser cet outil ?

1/ En mode projet

Comme je le disais plus haut, les développeurs pourront graviter autour de l’outil RESTClient de manière autonome . Chez NUBYtouch son utilisation est systématique : tel un contrat entre les équipes, il suffit que chacune s’y conforme, et le tour est joué !

2/ En cas de problème

Je m’adresse aux sociétés d’édition logiciel : un nouveau Client est difficile à trouver mais facile à perdre ! En cas de rupture de service ou anomalie bloquante, le risque est de s’enliser à chercher la responsabilité de l’erreur.
L’utilisation de cet outil permet en un instant de définir la provenance de l’erreur, en évitant les discussions sur l’origine du problème, en supprimant toute tension inutile.

Comment utiliser cet outil ?

La preuve par l’exemple ; les deux principaux outils que j’utilise sont le plugin RESTClient de Firefox, et le plugin Advanced Rest Client de Chrome.

Faisons un essai avec le plugin de Firefox :

> Lancer le plugin RESTClient
> Saisir les paramètres du flux ; par exemple :

Exemple de flux retournant une liste d'image en .png

Exemple de flux retournant une liste d’image en .png

Le paramétrage peut paraître compliqué pour certains, mais ne vous inquiétez pas, car la construction de l’export REST est à la charge du développeur Client, comme mentionné plus haut.

> Importer les paramètres en téléchargeant le fichier json ici, puis aller dans le menu « Favorite Requests » > « Import Favorite Requests » ; la requête apparaît alors dans le même menu (rafraîchir éventuellement la page).

En mode projet vous pourrez alors avoir un aperçu de l’état des flux ; ici on constate que le flux retourne bien (200 OK) la liste des images (sc1.png, sc2.png etc…)
En cas de problème (pas de 200 Ok mais un 400, 401, 404…), l’erreur vient de l’équipe de développement Client.
Si le flux est OK et que l’erreur subsiste sur smartphone ou tablette, c’est que l’erreur vient de l’Editeur.

Avantage de la démarche

> Visualisation les données brutes sortant du SI
> Recette fonctionnelle avec des jeux de données différents
> Livraison d’un travail achevé conforme et standard
> Élimination des allers-retours inutiles entre le Client et l’Editeur
> Meilleure efficacité dans la résolution d’incident
> Amélioration de la relation Client / Editeur

Cet outil de test augmente ainsi la productivité mobile, améliore la relation Client, et assure des délais tenus !

Si vous voulez en savoir davantage, n’hésitez pas à nous contacter.


Maxime PITOT
Owner NUBYtouch
Formateur en mobilité au SAE Institute

Vers une architecture mobile efficiente

Efficience et efficacité

Introduction

Un grand nombre de gens pensent encore que le développement d’une application native a un coût élevé, qui serait dû à l’aspect redondant du re-développement – ou portage – d’application.

C’est une idée reçue car il existe de nombreuses astuces techniques qui facilitent bon nombre de tâches et réduisent ainsi significativement les coûts de réalisation.

Dans un précédent article je vous ai parlé d’applications hybrides, qui ont la particularité d’engendrer un gain de productivité considérable à travers l’intégration intelligente de contenu WEB.

Aujourd’hui j’aborde la notion d’architecture mobile efficiente, répondant notamment à la problématique d’intégration de flux d’information hétérogène, qui oblige à se connecter aux multiples adaptateurs techniques – ou API (Application Programming Interface) des services concernés (YouTube, LinkedIn, Twitter, Dailymotion, Viadeo, Facebook, etc …)

Etude de cas

Rentrons dans le vif de la démonstration.
Etudions le cahier des charges suivant :

Vous devez afficher sur les terminaux iOS, Android, Blackberry et site web, les éléments ci-dessous :
> dernières vidéos YouTube
> fil de news Twitter
> contact LinkedIn

Solution 1 : l’approche efficace de Jean
Solution 2 : l’approche efficiente* de Pierre

Solution 1 : l’approche de Jean

Jean est un bon chef de projet technique junior ; il a étudié les spécificités de chaque plate-forme, et va affecter les tâches d’intégration des API’s aux différents développeurs, en leur demandant d’utiliser les librairies suivantes :

Pour le développeur iOS (iPhone / iPad) :
> YOUTUBE : utilisation de la librairie Objective-C
> TWITTER : librairie d’intégration sur iOS
> LINKEDIN : utilisation de la lib IosLinkedInAPI sur GitHub

Pour le développeur Android :
> YOUTUBE : utilisation de la librairie Java
> TWITTER : librairie Twitter4j
> LINKEDIN : utilisation de la lib Scribe

Pour le développeur ASP.NET (pages webs) :
> YOUTUBE : utilisation de la librairie .Net
> TWITTER : librairie LINK2Twitter
> LINKEDIN : utilisation de la lib ASPSnippets

Solution 2 : l’approche de Pierre

Pierre est un chef de projet technique senior ; il demande prioritairement au développeur ASP.NET d’utiliser les librairies qui le concernent (ci-dessus), pour ensuite exposer ces mêmes données via un Web Service (ou fil RSS – pseudo Web Service standardisé).
Ainsi les autres développeurs iOS et Android n’auront qu’à consommer le Web Service nouvellement créé pour y afficher les données concernées : tâche triviale sans commune mesure avec la difficulté d’intégration multiple d’API tierces.

Mot du coach

Jean a prévu l’intégration de toutes les API’s sans en oublier aucune.
Pierre a prévu seulement une seule intégration : au niveau du serveur.

C’est bien ce qui différencie la personne efficiente de la personne efficace :
Quelqu’un d’efficace fait tout bien.
Quelqu’un d’efficient fait bien les bonnes choses.

Calcul de la charge

Dans ce cas pratique si N représente le coût d’intégration moyen d’une librairie, Jean a budgété 3N x [nombre-de-plate-formes], soit ici 9N.
Pierre aura budgété 3N + développement et intégration classique de RSS soit au total environ 5N.

Ex : Fil Twitter sur l’app Euler Hermes (EH Research)

twitter

Lorsque Euler Hermes nous a confié la réalisation mobile universelle (iPhone, iPad, Android, Web), il a fallu intégrer le fil d’actualité Twitter. Nous avons donc créé un Web Service retournant simplement la chaîne de caractère correspondante.

L’accès à l’API Twitter (et toute la complexité que cela implique : authentification, appel, traitement, mise en forme personnalisée et mise en cache du résultat) a été traité une seule fois : au niveau du serveur d’émission de données.

CONCLUSION

Une fois de plus nous avons fait de sérieuses économies, sans toucher à la qualité de l’application. En effet celle-ci reste native, voire même plus performante dans la mesure où la complexité d’accès au service souhaité (YouTube, Twitter…) a été gérée en amont.

Cette solution d’architecture mobile efficiente augmente ainsi la productivité mobile et par conséquent en réduit le coût.

Si vous voulez en savoir davantage, n’hésitez pas à nous contacter.


Maxime PITOT
Owner NUBYtouch
Formateur en mobilité au SAE Institute

*Petite question du coach, quelle est la différence entre l’efficacité et l’efficience ?
Réponse dans cet article, section « Mot du coach » !

Le vrai potentiel de l’app hybride

Introduction

La définition des concepts informatiques évoluent intrinsèquement avec le progrès ; l’invention et l’innovation naissent par brainstorming ou sérendipité, dans une maturation balbutiante et muette ; viennent ensuite, avec un léger décalage, la verbalisation et la vulgarisation de cette nouveauté.
C’est ainsi qu’est apparu le terme d’app hybride : il fallait donner une définition à cette application native efficiente, celle qui savait intelligemment dispenser le contenu Web là où il le fallait et quand il le fallait, là ou la mutualisation entre les différents contenus apportait un bénéfice immense, tant en productivité qu’en terme de coût.

Avantages

Pendant longtemps il fallait choisir entre WebApp et AppNative, en fonction de critères plutôt variés (lire l’excellent article de Wilfried MPANDOU sur ce sujet : Native ou Web App, que choisir ?).
l’app hybride combine  les avantages de ces deux mondes :

  • Coût de développement réduit
  • Maintenance applicative allégée
  • Accès total aux fonctionnalités de l’appareil
  • Mise à jour instantanée pour le contenu web
  • Promotion via les stores (App Store, Google Play…)
  • Monétisation élargie (iAd, purchase Apple et Google Play)
  • Responsivité et impact émotionnel peu impacté

« Out of the box » ou « sur-mesure »

L’app hybride se décline en deux familles :

« Out of the box »

C’est le « prêt-à-porter » de l’app hybride ; l’analogie avec le textile est pertinente : de nombreuses boutiques font parfois de belles choses, et pour pas toujours très cher !
Voici une liste des principales solutions permettant rapidement de mettre en place un produit de ce type ; solutions DIY – pour Do It Yourself, à part peut-être les deux dernières qui sont à laisser aux mains des développeurs :
Mobile Conduit, InfiniteMonkeys, knack, appery.io, iBuildApp, appceleratorPhoneGap
On obtient alors des applications natives, qui disposent d’un contenu essentiellement web ; « trop de web », dirons-nous pour les solutions « Out of the box » ; c’est ainsi qu’intervient le « sur-mesure ».

« Sur-mesure »

Une connaissance manifeste du métier de l’ergonomie web mobile et une étude approfondie du cahier des charge va nous orienter vers les fonctionnalités hybrides à implémenter ; la question qui va se poser est  la suivante : quels écrans vont pouvoir être réalisés en web – et donc mutualisés pour les multiples plateformes (iOS, Android, Blackberry, Web online…) – et ce sans (trop) impacter l’experience utilisateur ?

Typiquement cela concerne :

  • Les formulaires complexes (contacts, questionnaires, quiz…)
  • Les écrans statiques riches composés d’images, de couleurs, de polices différentes  (page d’aide, mentions…)
  • Les concepts nativement web (nuage de mots, graphiques, wordmap…)

L’interactivité entre les pages web et l’app native est assurée par la remontée d’événement « attrapés » par l’application.
Ex : je clique sur un bouton de formulaire web, c’est détecté par l’application, qui prend la main et agit sur l’écran natif).

Cas pratiques

1. L’app Euler Hermes (EH Research)

Dans le cadre de la réalisation iPhone / iPad  que nous a confié Euler Hermes, concernant la carte des risques pays, nous nous sommes naturellement posé la question sur la faisabilité technique et la possibilité de mutualiser le développement d’une telle fonctionnalité ; Après reflexion, une worldmap HTML5 SVG, combiné à un écran détail natif semblait le plus pertinent et le moins coûteux, pour un résultat très propre.

support-article

Ainsi nous avons pu porter sans réelle difficulté d’intégration la map sur du multi-device, le plus délicat ayant été développé dans une techno nativement web pour cette fonctionnalité précise.

En terme de chiffrage, considération décisive pour un bon nombre des décideurs :
> si on définit la charge de réalisation de la map HTML5 à N jours, on peut dire que la charge additionnelle de portage est de N x 20% jours, alors qu’elle serait de N x 80% jours pour une techno non hybride ; un peu de Pareto dans la boucle illustre bien les avantages en terme de rentabilité.

2. L’app Natixis PCA (iOS & Blackberry)

Dans cette application, réalisé pour le groupe Natixis, le challenge était d’apporter un mode offline sur un produit de gestion de crise, où fortuitement (et malheureusement) un incident peut endommager la diffusion des informations des serveurs centraux.
Il fallait également pouvoir créer du contenu à la volée (nouveaux écrans).

C’est ainsi que l’idée d’un mini-site web mobile est venue, avec une aspiration de contenu dès le démarrage : Tous les écrans (page) webs sont ainsi téléchargés dans l’app pour stockage ultérieur sans réseau, et ceci quelque soit le device concerné :

natixispca

Intégration web mobile en offline

Conclusion

L’app hybride, tout comme les sites web traditionnels, couvre un large spectre en termes de qualité et de coût ; avec une particularité commune : une augmentation de la productivité mobile.

Si vous voulez en savoir davantage, n’hésitez pas à nous contacter.


Maxime PITOT
Owner NUBYtouch
Formateur en mobilité au SAE Institute

Présence sur mobile : par où commencer ?

La présence sur mobile est devenue incontournable de nos jours.

L’heure n’est plus à l’innovation où certaines sociétés, aussi peu étaient-elles, décidaient d’anticiper ce mouvement de fond et de porter leur identité sur les appareils de l’information de demain.

Un peu comme le monde du Web il y a plus de dix ans, les entreprises aujourd’hui doivent être présentes sur tactile, et être disponibles aux utilisateurs nomades en demande d’informations, n’importe où, n’importe quand.

Le deux principaux freins à l’adoption du m-marketing résident dans les éléments suivants :

  1. la méconnaissance de la culture mobile
  2. la méconnaissance des solutions techniques possibles (site Responsive, WebApp, appli natives)
  3. le coût de réalisation

Effectivement, avant de se lancer dans le mobile, il faut s’informer sur ces différents points. Vous trouverez dans cet article ce qu’il me semble important de savoir.

1. Habitude et culture mobile

On est bien loin de la souris qui pointe son curseur sur une zone de deux millimètres carrés ; ici, on utilise les doigts ; on ne clique pas, on fait du multi-touch ; la surface de l’écran est petite, ce qui nécessite de repenser et de simplifier drastiquement l’interface ; et comme si cela ne suffisait pas, on y ajoute de multiples nouveautés comme la géolocalisation (regardez où se trouve mon siège social sur la carte), la prise de vue (je scanne un code-barre), la dématérialisation (je signe le contrat sur iPad), etc…

Bref, mon conseil est tout simple, pour se familiariser avec le tactile, téléchargez 1001 applications, analysez-les, observez ce qu’elles vous apportent, et lancez-vous dans le cahier des charges !

2. Solutions techniques

Là encore, il y a des choses à savoir ; on peut distinguer trois orientations :

1/ Site Responsive : c’est une extension de votre site Internet, qui va « automatiquement » s’adapter à la taille du terminal – smartphone ou tablette ; pour illustration, si vous avez trois colonnes sur votre page d’accueil, vous en aurez deux sur tablettes, et une sur mobile (c’est intentionnellement simplifié, sachez que vous pouvez, via une détection du navigateur, rediriger l’utilisateur vers des pages mobiles davantage personnalisées).

2/ WebApp : une webApp n’est pas intégrée au site Internet ; par définition c’est une application au sens thématique du terme, qui va apporter une utilisation bien définie, et bien souvent utiliser les possibilités de l’appareil (géolocalisation, player vidéo, envoi SMS…)

3/ Appli native : alors que la webApp accède au contenu distant sur le Web, l’application native est, elle, téléchargée sur votre appareil, assurant une réactivité incomparable ; de là réside l’essentiel du « Whaou effect » : l’interface réagit instantanément au toucher, il n’y a aucun temps de latence !
Bien évidemment, la réactivité  est nécessaire mais pas suffisante  ; le chemin vers la killer app nécessite de respecter les bonnes pratiques du développement mobile, cela va de soi !

3. Coût de réalisation

La case départ est de rendre votre site Internet disponible sur mobile ; attention, quand je dis disponible, j’entends par là LISIBLE, car oui votre site Internet est accessible via le navigateur mobile, mais il faut alors une bonne dose de courage et de zoom pour lire l’écran, un peu comme si vous étiez à 20 centimètres d’un écran de cinéma !

Faire évoluer un site Internet pour qu’il s’adapte sur les différents écrans nécessite généralement de simples connaissances Web (HTML, CSS), et représente un coût relativement peu important ; c’est ce qu’on appelle un site Responsive : qui répond aux différentes tailles d’écrans.

Conseil No1 : Rendre votre site Responsive

Ensuite, les deux questions qui se posent sont les suivantes :

A quel public vous adressez-vous ?

A titre d’exemple, un parti politique (ou la grande distribution) va chercher à atteindre en « marketing direct » tous les terminaux possibles, c’est-à-dire les utilisateurs iPhone, Android, Blackberry, WindowsPhone etc….
Cela implique donc de lancer une réalisation multi-cible ; on optera donc davantage vers une webApp, où la technologie est unique (techno web) et les coûts logiquement moins élevés.

Quel est votre budget ?

Suivant vos capacités de financement, vous pouvez envisager de réaliser des applis natives sur les principales plateformes (iOS et Android) ; On imagine bien qu’un coût distribué  est plus onéreux qu’un coût unique de WebApp ; Cela est plutôt vrai ; cependant, gardez à l’esprit que le coût n’est pas proportionnel au nombre de plateformes cibles : il faut distinguer la 1ère réalisation du PORTAGE, qui est nettement moins chère (il suffit de « convertir » le code, les principales questions existentielles du projet ont été réglées à ce stade).

Conseil No2 : Optez pour une webApp si vous avez peu de moyen et une cible large

Si par la suite vous avez davantage de budget, ou bien une idée marketing thématique particulière, lancez un développement sur app native en allant chercher le buzz ; par exemple, toujours dans notre exemple de parti politique, on imagine une app Android « Mon Bayrou 2017 » (n’y voyez surtout pas un militantisme politique :)), où le ludique et fun seraient mis en avant.

Conseil No3 : Offrez-vous une présence native sur une thématique précise en allant chercher le buzz

En résumé :

Ces conseils doivent être des éléments structurants à votre raisonnement de stratégie marketing ; vous allez, logiquement et je l’espère, combiner ces conseils pour créer votre propre solution : par exemple l’entreprise « Booking.com » a d’abord créé son site Web Mobile, avant de décliner de multiples applications natives sur les stores ; la dernière, nommée « Tonight », a une thématique particulière et ciblée : les meilleurs hôtels pour ce soir ; simple, et efficace.

D’autres variables rentrent en ligne de compte, par exemple la maturité de votre plateforme de Web Services, élément fondamental dans l’Emission de données ; mais on rentre dans des considérations techniques, cela fera l’objet d’un autre article.


Maxime PITOT
Owner NUBYtouch
Formateur en mobilité au SAE Institute