Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

  • "envoyé depuis mon iPhone" : phonegap & Co


    Si vous êtes blogger hautetfort ou Blogspirit, vous avez peut-être lu ici ou là qu'une application iPhone était en préparation. Voici les coulisses de la préparation de cette nouveauté.

    Nous avions dans un premier temps la ferme intention de sous-traiter ce développement (partie client). Il fallait aller vite, être efficace. Nous avons lancé un appel d'offres sachant que travailler avec nous sur ces sujets est signe de travail récurrent. Nous avons reçu une vingtaine de réponses de 3000 euros à presque 30 000 ! Les uns, ne donnant guère de garanties et les autres franchement exorbitants. Même 15 kE, pour une offre sérieuse, nous semblait trop cher car le périmètre est limité à 7 services à intégrer (3 fonctions en réalité).

    Comment faire pour développer une application sans connaissance des SDK iPhone ou Androïd ?
    Finalement, nous étions en short list avec des prestataires et un ami me parle de PhoneGap, un logiciel open source qui permet de générer une appli iPhone ou Androïd en écrivant du Javascript et du html avec l'avantage d'être portable iPhone, androïd et BlackBerry. Très intéressant. 
    De nature curieuse, je demande à un développeur de me faire une étude faisabilité et un prototype ainsi qu'une étude comparative avec d'autres concurrents.
    PhoneGap ne transforme pas du Javascript en code natif. Simplement, phone gap utilise un web kit. En somme, en démarrant l'appli, vous ouvrez un navigateur qui lit le html et interprète le Javascript. PhoneGap possède une librairie basée sur jquery qui permet de dialoguer avec des webservices et surtout l'appareil photo, la géolocalisation, l'accéléromètre, ... Comme standard de dialogue nous avons retenu json qui est peu verbeux et facilement lisible en Javascript. Nous avons retenu cette solution.

    A quelques jours du lancement, Apple a lancer son nouveau SDK, son nouvel iOS ce qui a provoqué des bugs et des difficultés pour compiler PhoneGap avec la version iOS. Nous avons choisi d'attendre la nouvelle release de PhoneGap. Cette contrainte nous l'avons découvert alors que nous étions dans les starting block du lancement dans l'appstore ! A l'inverse, nous pouvons dire que la mise à jour de phone gap nous fait économiser du temps puisque si nous avions développé un code natif nous aurions été obligé de prendre à notre charge le debug. Cette mise à jour a couté 4 mois de retard au projet. Une fois les solutions trouvées, il faut remobiliser l'équipe, trouver des créneaux. Dure !

    Nous avons lancé il y a quelques jours la soumission dans l'appstore. Il faut dire que cette soumission est un véritable examen de passage ! Nous avions peur que PhoneGap ne soit pas considéré par Apple comme un service fiable. Nos lectures sur internet sont sans appel, pas de problème avec cet outil ! Nous avons été retenu du premier coup. Bravo !

    Pour conclure, je retiens cependant une règle capitale dans le choix de la solution qui se résume à une question pour un éditeur de service comme nous : l'appli mobile est elle stratégique pour le business modèle du projet ?
    - non, c'est seulement un plus. On gagnera à sous traiter l'appli.
    - oui, mais les mises à jour sont peu fréquentes et les évolutions seront rares (release semestrielle). Un outil comme PhoneGap sera adapté.
    - oui, mais les ambitions de l'appli amène à des mises à jour régulières. Développer une appli en natif en conservant la MOA et la MOE en interne me semble plus adapté.

  • le Temps m'a tuer (oups)

    tempsVous croyez que ce blog est mort tout ça parceque je vous ai laissé avec feu mon grand père ?

    Pas du tout. En fait je tue le temps. Eh oui, quand ce blog n'avance pas, je ne recule pas ! Même si pour avancer il faut savoir se poser, et prendre du recul. Comprenez-vous ?

    Pourtant quand je n'écris pas, c'est que je suis déborder (version neutre) ou que je me laisse déborder (version sévère). Hors s'investir dans un projet ou une mission de manière déraisonnable, sans relever la tête, comme tout passionné suggère aussi une perte de certains "capteurs" sensoriels.  Et dans mon activité, j'ai besoin que mes capteurs soient en exergue. Les capteurs, ils permettent d'évaluer une charge de travail, anticiper un changement de produit, orienter des développements, ...

    Comme j'ai passé le cap du déni en arrêtant de faire l'autruche sur mes projets, de la colère en reprochant  au "système" de ne pas avoir assez de moyens en m'offrant des journées de 72h, de la fatalité et de la dépression à force de me dire "on s'en sortira jamais", me voilà dans la phase d'acceptation de mon deuil.

    Quoi un deuil ? Oui le deuil du changement qui s'opère dans la croissance de mon entreprise, le virage qui va faire que elle va passer en mode adulte, que les choses changent, qu'on est plus quatre dans l'équipe, que je ne peux plus faire d'opérationnel, que ...

    Et l'écriture, c'est l'occasion de prendre conscience de certaines choses. La lecture c'est l'occasion de partager des évidences ou mettre le doigt sur les petits riens croustillants de la vie quotidienne.

    Cette note a été largement mais librement inspiré par "petit deuils en entreprise" de Jacques-Antoine Malarewicz qui explique avec intérêt que chaque changement en entreprise suppose un deuil souvent niée dans notre société. Je recommande.