L’API Streaming de Twitter avec le HttpClient .net

La recherche et le streaming

Un des fonctionnalités intéressantes de l’API Twitter est l’utilisation du Streaming. Tout comme la recherche, cette API nous permet de spécifier un mot clé et de récupérer les tweets liés à ce mot clé. Cet article a pour but de vous montrer la différence entre la recherche et le streaming sur l’API Twitter ainsi que l’implémentation de ce streaming en C#.

La différence entre l’API de recherche et l’API de streaming réside en la manière de récupérer les tweets. Avec la première, vous envoyez une requête au serveur Twitter qui vous retourne alors page par page les tweets correspondant à la recherche dans une seule et même réponse. Le fonctionnement est celui d’un échange client-serveur classique :


(crédits image : https://dev.twitter.com )

Principe du streaming

Concernant le streaming, les tweets retournés ne vont pas l’être dans une seule et même réponse. En effet le serveur maintiendra la connexion indéfiniment et dès qu’un nouveau tweet concerné par la recherche faite va être soumis à Twitter, celui ci va nous être retourné dans la foulée. Ce cas d’utilisation est notamment intéressant dans des applications de type “live tweet” :

(crédits image : https://dev.twitter.com )

Implémentation en C#

L’url de requête sera https://stream.twitter.com/1.1/statuses/filter.json en POST. A cela s’ajoute un ou plusieurs paramètres. Pour une utilisation de base, nous ajouterons le paramètre “track” qui aura comme valeur votre recherche (un hashtag ou tout simplement un mot ).

Cette requête ne semble pas compliquée, mais l’extrait de code suivant, qui fonctionne dans le cas d’une simple recherche, va ici échouer. Le souci ne vient pas directement de ce code mais de la librairie OAuth que j’avais réalisée suite à un de mes précédents articles (code source disponible en une seule classe ici : https://skydrive.live.com/?cid=230FED47B214039C&id=230FED47B214039C%212851 )

static async void ComputeStreaming(string search)
{
    OAuthRequester.ComputeHmacSha1 = ComputeHMACSHA1Hash;
    string consumerKey = "yourConsumerKey";
    string consumerSecret = "yourConsumerSecret";
    string oauthToken = "yourOAuthToken";
    string oAuthTokenSecret = "yourTokenSecret";
    string searchUrl = 
"https://stream.twitter.com/1.1/statuses/filter.json"; Dictionary<string, string> contentParams = new Dictionary<string, string>(); contentParams.Add("track", search); var searchRequest = OAuthRequester.SignRequest(HttpMethod.Post,
searchUrl, consumerKey, consumerSecret, contentParams,
oauthToken, oAuthTokenSecret);
using (StreamReader reader = new StreamReader(
await (await searchRequest).Content.ReadAsStreamAsync())) { while (!reader.EndOfStream) { string result = reader.ReadLine(); JObject root = JObject.Parse(result); Console.WriteLine(root["text"].ToString()); } } }

Il n’y pas forcément d’erreur de conception dans ma librairie, l’erreur serait similaire avec l’utilisation de “WebClient” ou “WebHttpRequest”. De la même manière, la requête sera lancée, mais rien ne sera renvoyé et au bout d’une minute, vous recevrez un timeout. Le souci provient de la manière dont HttpClient traite la réponse par défaut, le client a bien commencé à recevoir la réponse, mais il attend d’avoir reçu tous le contenu avant de renvoyer votre objet “HttpResponseMessage”. Or, le principe du streaming est de laisser la connexion ouverte et de recevoir le contenu au fur et à mesure, donc HttpClient ne peut pas gérer le cas de figure de cette manière. Mais, heureusement, il suffit d’une petite modification pour gérer le cas particulier des réponses sous forme de flux et non de sous forme de contenu entier. Il suffit de modifier l’appel de la méthode “client.SendAsync(…)”, dans notre cas, nous utiliserons la surcharge suivante:

HttpResponseMessage response = await client.SendAsync(request,
HttpCompletionOption.ResponseHeadersRead);

La différence réside en l’ajout du paramètre de type “HttpCompletionOption” qui, s’il est omis, prend par défaut la valeur “ResponseContentRead” qui signifie que HttpClient attend de recevoir tout le contenu de la réponse avant de la traiter. La valeur qui nous intéresse ici est “ResponseHeaderRead” qui signifie que la réponse sera traitée dès que les header seront reçus. Le contenu en lui même sera reçu plus tard, lors de l’appel de “ReadAsStreamAsync()”. Avec la modification de la requête, vous pouvez à présent tester le code un peu plus haut qui fonctionnera cette fois-ci (testez avec un sujet populaire du moment pour voir le streaming agir ).

Conclusion

Parfois complexe à utiliser dans certains SDK, l’API streaming de Twitter consiste en une simple requête en POST. La seule petite difficulté est de ne pas attendre de recevoir tous le contenu pour traiter la requête comme le font par défaut les clients HTTP en .net mais de la traiter dès réception des headers. HttpClient permet ce traitement particulier avec la modification du paramètre HttpCompletionOption.
La mise à jour de la classe helper OAuth 1.0 est disponible ici.

Par Mathieu Hollebecq

Récupérer une session perdue sous firefox

Je suis un grand fan des onglets mais il arrive que Firefox crashe inopinément et me perde ma 100aine de sites que je dois regarder…

Mais on peut heureusement les récupérer !

Sous Windows (et uniquement sous Windows)

Attention : Si vous aviez plusieurs fenêtres ouvertes et que vous avez fermé par inadvertance la mauvaise, vous pouvez peut-être encore tenter de cliquer sur “historique” dans le menu (appuyez sur la touche alt pour l’ouvrir) puis “fenêtres récemment fermées”. Sinon, si c’est dû à un caprice de firefox après fermeture, essayez la procédure suivante :

1. Fermez Firefox

2. Rendez-vous dans votre dossier AppData/Roaming/Mozilla/Firefox/Profiles ou entrez directement %APPDATA%/Mozilla/Firefox/Profiles dans la barre d’adresse de l’explorer.

image

3. Ensuite ouvrez le répertoire au nom bizarre : xxxxx.default.

Et cherchez un fichier répondant au nom de sessionstore.bak. Vérifiez que le contenu correspond bien à vos onglets en l’ouvrant avec un éditeur de texte (clic droit / Ouvrir avec…). Si ce n’est pas les bons sites, cherchez le fichier sessionstore.bak le plus récent (il peut y en avoir plusieurs).

4. Copiez-le dans un endroit sûr au cas-où puis renommez-le en sessionstore.js

5. Réouvrez Firefox, vos onglets devrez être là ! Dans ce cas, vous pouvez supprimer la copie faite au point 4 (Ne touchez plus au sessionstore.js !)

6. Partagez cet article, vous sauverez sûrement d’autres personnes !

PS : Si vous ne trouvez malheureusement pas votre sessionstore dans ce répertoire, il est possible que vous n’ayez pas choisi de conserver vos onglets, ou que votre version de firefox soit trop vieille. Dans ce cas, je suis désolé, cet article ne pourra vous aider plus…

Par JCVASSELON

[Windows 8] Réimplémenter le RemoveBackEntry

Dans le cas d’un projet, il me fallait empêcher le retour sur la page précédente mais revenir sur une page particulière. Exemple : MainPage –> Page Sommaire –> Page 1 –> Page 2 –> Page 3
Le bouton précédent depuis les pages 1 à 3 devait me ramener sur la page Sommaire.

Ma première réflexion a été d’utiliser le GoBack juste avant de naviguer vers la page suivante. Sur PC, ce retour en arrière ne se voyait pas mais sur une tablette ARM, le chargement de la page précédente puis de la suivante était flagrant et inésthétique.

J’ai donc cherché le RemoveBackEntry comme il existe sur Windows Phone pour supprimer la page précédente, mais malheureusement il n’existe pas en WinRT… Mais il est possible de manipuler la pile de navigation !

Manipuler la pile de navigation

La méthode GetNavigationState d’un objet Frame nous permet de récupérer la pile de navigation sérialisée sous forme de string tandis que SetNavigationState nous permet de la modifier.

Avertissement

La documentation du GetNavigationState, le précise bien. Il est formellement déconseillé de le faire, cette méthode est utilisée en interne et la manière de sérialiser peut être modifiée par Microsoft dans une version future de Windows. Son usage permet actuellement de stocker la page courante de l’utilisateur lors de la fermeture de l’application et de le ramener sur cette page à la prochaine ouverture.

Autre point, la déserialisation est impossible si vous passez des objets entre 2 pages. Ce système ne marchera que si vous faites une navigation basique d’une page à une autre. Si vous souhaitez passer des objets utilisez des Messengers ou simplement un Cache, mais ce n’est pas le sujet de l’article.

Mettons les mains dans le cambouis

La méthode GetNavigationState() va nous retourner une chaîne sous cette forme :

1,3,2,31,MonNamespace.MainPage,12,0,40,MonNamespace.Sommaire,0,33,MonNamespace.Page1,0

Découpons la chaînes et expliquons chaque partie :

1,3,2 :

  • 1, je ne sais pas… Certainement le signalement du début de la chaîne
  • 3, correspond au nombre de pages dans la pile
  • 2, à l’id de la page courante

31, MonNamespace.MainPage, 12, 0

  • 31 correspond à l’id du type de la page chargée
  • MonNamespace.MainPage est le type de la page chargée
  • 12, aucune idée, ce nombre n’est présent que dans l’ensemble lié à la 1ère page
  • 0, je pense que c’est le séparateur entre chaque page, on le retrouve à la fin de chaque page chargée

40,MonNamespace.Sommaire,0

  • 40 correspond à l’id du type de la page chargée
  • MonNamespace.Sommaire est le type de la page chargée
  • 0, idem que précédemment

Vous avez compris la structure. L’idée est donc, pour supprimer le dernier élément, de le retirer de la chaîne de caractère, et de décrémenter l’ID de la page courante ainsi que le nombre de pages chargées.

Pour cela, je me suis créé une méthode d’extension à la classe Frame :

public static classFrameExtension
{
public static void RemoveBackEntry(thisFrameframe)
{
varparts = frame.GetNavigationState().Split(‘,’);
varcount =Int32.Parse(parts[1]);

if(count > 1)
{
parts[1] = (
int.Parse(parts[1]) – 1).ToString();
parts[2] = (
int.Parse(parts[2]) – 1).ToString();
varstate =String.Join(« , », parts, 0, parts.Length – 3);

frame.SetNavigationState(state);
}
}
}

Quelques précisions

Il nous suffit donc de faire un this.Frame.RemoveBackEntry pour supprimer la dernière page visitée de notre pile de navigation. L’appel sur GoBack() nous ramènera sur la page encore précédente. Exemple : MainPage –> SommairePage-> Page1->RemoveBackEntry->Page2. Depuis la page 2, GoBack nous ramènera sur SommairePage.

Attention, l’appel du SetNavigationState() lance une navigation vers la page courante (normal vu qu’il doit être appelé au démarrage de l’application pour repositionner l’utilisateur sur la page sur laquelle il était) du coup, le “OnNavigatedTo” de votre page sera appelé en mode GoBack, pensez-y si vous avez un comportement bizarre.

Par JCVASSELON

OAuth 1.0 en bref

Cette article fait partie d’une série dédiée au protocole OAuth

1 – OAuth 1.0 en bref
2 – Exemple de Twitter avec C# et HttpClient

Aujourd’hui utilisé par bon nombre de services populaires, comme Twitter, Tumblr ou encore Facebook, pour exposer leur API publique, OAuth est un protocole d’autorisation qui en est aujourd’hui à sa version 2.0. Il réside certaines différences assez notables entre la version 1.0 et la plus récente, la 2.0. Néanmoins, ce protocole est encore utilisé dans sa version 1.0 par des services très populaires, comme Twitter, c’est donc pour cela que cet article traitera de la version 1.0.

Cet article se veut volontairement détaché de tout langage de programmation pour cibler n’importe quel développeur curieux. Néanmoins il sera suivi d’un article d’exemple d’implémentation de l’OAuth 1.0 en C# pour effectuer une requête à l’API Twitter

Pourquoi OAuth ?

Avant d’expliquer pourquoi OAuth, mettons d’abord en évidence les différents acteurs impliqués dans ce protocole:

  • Le propriétaire des ressources, autrement dit : l’utilisateur final. Il souhaite accéder à un service sur un serveur hébergeant des données qui lui sont propres.
  • Le serveur : le service en lui même hébergeant les ressources de l’utilisateur et mettant en place une API utilisable par des applications tierces.
  • Le client : application ou site web tiers non affilié au serveur fournissant le service. Ce client doit être explicitement autorisé par le propriétaire des ressources d’accéder aux ressources appartenant au client sur le serveur.

Pour donner un exemple de ces trois entités, imaginez un utilisateur final ayant installé une application sur son Smartphone permettant de faire des achats en ligne. Une fois ses achats effectués, l’utilisateur est invité par l’application à mettre à jour son statut Facebook pour montrer à ses amis qu’il a utilisé cette application pour acheter certaines choses. Ainsi, l’application “facilite” le travail de l’utilisateur en pré-remplissant le texte du statut et en y ajoutant une photo correspondante, il suffit alors à l’utilisateur de valider directement depuis l’application pour voir son statut Facebook mis à jour. Dans cet exemple, le propriétaire de ressources est l’utilisateur de l’application, l’application est le client et Facebook est le serveur. Ainsi l’utilisateur possède des informations personnelles (propriétaire de ressources) sur Facebook (serveur) et délègue la rédaction de son statut à l’application smartphone (le client).

OAuth a vu le jour face au potentiel risque de sécurité qui pouvait se poser lorsque le propriétaire de ressources ne pouvait s’authentifier à une API d’un serveur par le biais d’un client tiers que par son couple identifiant/mot de passe. Ainsi pour maintenir l’authentification, le client doit garder une trace du mot de passe de l’utilisateur en clair ! De même l’utilisateur ne peut ni donner un accès partiel à un client (par exemple de la lecture seule) ni révoquer l’accès à un client (à moins de modifier son mot de passe, mais cela révoquerai TOUT les accès des clients tiers).

Comme alternative à ça, OAuth propose l’utilisation d’un jeton (access token) propre à l’utilisateur et au client pouvant être valide uniquement dans un certain laps de temps et pour seulement une partie définie des services du serveur. Ainsi, l’utilisateur n’expose à aucun moment son mot de passe au client, il peut donner un accès restreint à ses ressources et peut révoquer ses accès comme bon lui semble sans avoir à changer son mot de passe et sans modifier les accès d’autres clients tiers au service.

OAuth en bref

Processus

Le processus simplifié d’obtention du jeton d’accès est le suivant : le serveur fournit au client sa propre clé unique d’authentification (consumer key) avec sa clé privée (consumer secret). Cette clé du client sera inclue dans une url de redirection envoyée au propriétaire de ressource dirigée vers la page d’authentification du serveur. Ainsi l’utilisateur s’identifie directement au serveur sans fournir son identifiant et son mot de passe au client, et le serveur (grâce à la consumer key contenue dans la requête) pourra identifier le client pour afficher clairement à l’utilisateur quels droits et à qui il est sur le point d’octroyer. Une fois l’authentification sur le serveur faite, un jeton d’accès (access token) sera généré et renvoyé au client (identifié par sa clé ).

Pour faire une comparaison simple de ce que représente un access token, imaginez un parc d’attraction, un trousseau de clé ouvre ce parc et toutes ses attractions, mais pour donner au public l’accès au parc, le gérant ne va pas, en toute logique, faire des copies du trousseau de clés pour les donner aux visiteurs car de cette manière il leur donne accès à TOUT le parc, même les zones interdites et cet accès sera impossible à révoquer, sauf en changeant les serrures, mais changer les serrures interdira alors l’accès à tous les visiteurs ayant eu les clés et pas juste à celui à qui l’on veut interdire l’accès. Au lieu de donner un trousseau, on va simplement donner à chacun un ticket nominatif et chaque ticket aura un type (par exemple “enfant” pour juste les attractions enfantines, un ticket “premium” donnant accès aux spectacles du soir, etc…) et vérifier ce ticket à l’entrée de chaque attraction, ainsi seules les attractions autorisées par le type du ticket seront accessibles et si un visiteur ne respecte pas le règlement intérieur on peut révoquer son ticket sans gêner l’accès des autres visiteurs. De même, le ticket ne sera valable que durant un nombre précis de jours, et non à vie.

Etape par étape:

1 – Le client, identifié par sa clé unique, fait une demande de oauth token au serveur en signant la requête avec sa clé privée.
2 – L’utilisateur est redirigé vers une url sur laquelle il est invité à s’authentifier. Le oauth token doit être fourni soit en paramètre dans l’url soit fourni directement par l’utilisateur.
3 – L’utilisateur s’authentifie et accepte de fournir au client l’accès à ses données via l’API.
4 – Un access token et un access token secret propres à l’utilisateur et au client sont envoyés au client. Plusieurs manières peuvent opérer:
4.a : Si le client est capable de recevoir une requête du serveur, celui ci lui envoi directement la paire de token
4.b : Si le client n’est pas capable de recevoir de requête du serveur (application mobile ou application bureau), un code “PIN” est fourni à l’utilisateur et ce dernier le fourni au client. Le client doit alors refaire une requête au serveur en incluant son oauth token et le PIN de l’utilisateur pour recevoir en réponse le couple d’access token.
5 – A présent le client peut accéder aux données de l’utilisateur en utilisant sa consumer key et l’access token de l’utilisateur tout en signant la requête par le couple consumer secret et access token secret.

(Schéma d’authentification OAuth, cliquez pour voir l’image originale)

Construire et signer les requêtes

Paramètres OAuth

Une requête OAuth consiste en une requête HTTP classique mis à part que celle ci doit être signée par une clé privée. Pour signer la requête, il convient d’abord de distinguer deux types de paramètres qui devront être donnés à la requête: les paramètres OAuth et les autres paramètres liés au service demandé.

Les paramètres oauth sont au nombre de sept:
oauth_nonce : une chaine de caractère aléatoire
oauth_timestamp : nombre de secondes écoulées depuis le 1er janvier 1970
oauth_version : version du protocole, 1.0 dans notre cas
oauth_signature_method : méthode utilisée pour signer la requête, oauth supporte “PLAINTEXT”, “HMAC-SHA1” et “RSA_SHA1”. Néanmoins, les serveurs sont libres de ne pas supporter toutes ces méthodes. Pour la suite nous parlerons de la méthode “ »HMAC-SHA1”
oauth_consumer_key : la consumer key du client
oauth_token : l’access token (uniquement lorsque l’on a effectivement ce token, si on ne l’a pas, on omet ce paramètre)
oauth_signature : la signature de la requête

Le nonce et le timestamp peuvent servir au serveur s’il souhaite limiter le nombre de requêtes avec un même couple timestamp/nonce.

Signer la requête

(NOTE : n’étant pas sur de la traduction française du terme anglophone “percent encode”, j’utiliserais simplement le terme “encoder” pour faire référence à cet encodage. Il consiste à encoder, pour tout les caractères qui ne sont pas alphanumériques ou bien dans l’ensemble “-._~”, par le caractère pourcent ( % ) suivi de la représentation hexadécimale majuscule du caractère, par exemple “:” donne “%3A” )

Signer la requête consiste en la génération d’un signature base string puis de son hachage avec HMAC-SHA1 (hachage SHA1 mais en utilisant une clé de hachage ). La signature base string est composé de (dans l’ordre EXACT au caractère et à l’encodage près ! ) :

  • La méthode HTTP en majuscule (GET, POST, DELETE,….)
  • Un caractère ‘&’
  • L’url de base (sans les paramètres GET) encodée
  • Un caractère ‘&’
  • L’ensemble des paramètres placés de la manière suivante :
    • Les paramètres doivent être placés par ordre alphabétique de leur nom
    • Chaque paramètre est séparé par un ‘&’
    • Le nom et la valeur de chaque paramètre sont placés ainsi : le nom encodé, le caractère ‘=’ et la valeur encodée (s’il n’y a pas de valeur, nous ne plaçons rien entre le ‘=’ et le ‘&’ séparant du paramètre suivant)

Une fois la signature base string obtenue, nous la hachons avec la ou les clés privées concaténées de la manière suivante:
-La clé consumer secret
-Un caractère ‘&’
-Si l’utilisation de l’access token secret s’applique, nous la concaténons, sinon nous nous arrêtons là pour la formation de la clé de hachage.
 

Obtenir l’Authorization Header

L’authorization header sera une information placée dans le header “Authorization” de la requête. Il contiendra les paramètres oauth utilisés précédemment en y ajoutant la signature. C’est à partir de cet authorization header que le serveur récupèrera les informations lui permettant ou non d’autoriser la requête, cet header sera formé de la manière suivante:

  • le mot  “OAuth” suivi d’un espace
  • chaque paramètre oauth placés de la manière suivante
    • Chaque paramètre est séparé par un espace
    • Le nom et la valeur de chaque paramètre sont placés ainsi : le nom, le caractère ‘=’, le caractère ‘ »’ (double quote), la valeur encodée et un autre caractère ‘ »’ (double quote)

Puis il ne manque plus qu’à renseigner le header “Authorization” avec la valeur obtenue précédemment.

Vérifications

Une fois la requête construite et signée, il ne vous manque plus qu’à lui ajouter les autres paramètres (tous ceux qui ne commencent pas par “oauth_”); pour la méthode HTTP GET en mettant les paramètres dans l’url, pour les autres méthodes dans le header “Content”.

Lors du développement, à des fins de tests et de vérifications, je vous conseille d’utiliser la console de test oauth de Linkedin. Si vous lui fournissez les paramètres qu’elle demande, elle vous fournira la signature base string, la signature ainsi que l’authorization header que vous devriez obtenir. Etant donné que cette console de test ne produit aucune vrai requête à l’url que vous lui fournissez, rien ne vous empêche de ne pas lui fournir vos vrais clé mais plutôt des fausses clés que vous utilisez pour tester simplement la construction de la signature et des header.

Pour une documentation beaucoup plus exhaustive, vous pouvez consulter la norme RFC 5849 (en anglais).

Par Mathieu Hollebecq

Ouvrir deux instances de Skype en simultané

Depuis la migration de Windows Live Messenger vers Skype, certains (dont moi) se retrouvent avec deux comptes Skype à utiliser en simultané : notre ancien compte hotmail/.net passport/msn/live/microsoft et notre « vrai » compte Skype. Or, Skype ne peut lancer de base qu’une seule instance en passant par l’interface graphique. Mais cela est sans compter notre bonne vieille ligne de commande et nos fichiers .bat 😉

Pour cela, créez un nouveau fichier texte que vous nommez comme vous le voulez en remplaçant l’extention « .txt » par « .bat » puis à l’intérieur vous écrivez entre double quote le chemin d’accès à l’exécutable de Skype, et enfin vous rajoutez derrière « /secondary ». Chez moi cela donne :

« C:\Program Files (x86)\Skype\Phone\Skype.exe » /secondary

Vous n’avez alors plus qu’à cliquer sur votre fichier .bat pour lancer une seconde instance de Skype.

Par

[WP] Afficher l’image d’un contact

Pour les besoins d’un projet il m’a fallu afficher les images des contacts de l’utilisateur.

L’objet Contact qui défini notre contact contient une méthode GetPicture() qui nous retourne en Stream son image. Nous pouvons donc soit l’enregistrer, soit faire un converter pour l’afficher directement !

Voici le code dans le cas du converter :

C#

public class ContactPictureConverter : IValueConverter
    {
        public object Convert(object value,
            Type targetType,
            object parameter,
            System.Globalization.CultureInfo culture)
        {
            Contact c = value as Contact;
            if (c == null) return null;

            System.IO.Stream imageStream = c.GetPicture();
            if (null != imageStream)
                return PictureDecoder.DecodeJpeg(imageStream);

            return null;
        }

        public object ConvertBack(object value, 
            Type targetType, 
            object parameter, 
            System.Globalization.CultureInfo culture)
        {
            throw new NotImplementedException();
        }
    }

Ce converter s’occupe de récupérer un stream représentant l’image du contact concerné et le retourne sous forme d’image.

Déclarez ensuite votre Converter dans votre fichier de ressources et ajoutez une image dans votre xaml avec dans la Source, le contact visé et ce converter :

<Image Source= »{Binding MyContact, Converter={StaticResource ContactPictureConverter}} » />

Par JC VASSELON

L’Imagine Cup, cette grande école

Qu’est-ce que l’Imagine Cup ?

L’Imagine Cup est un concours organisé depuis plus de 10 ans par Microsoft. Il est souvent cité comme étant les “Jeux olympiques du numérique”. Pour l’avoir vécu c’est un peu ça, une compétition technique pluri-disciplinaire qui consiste à faire de belles choses grâce aux outils à notre disposition. Les équipes souvent très “geeks” au début s’ouvrent maintenant de plus en plus à d’autres étudiants ayant des compétences business, design ou marketing.

On voit d’ailleurs de plus en plus de projets Imagine Cup remporter ou faire des podiums lors des Startup Weekends (http://startupweekend.org/) ce qui nous montre la professionnalisation de ce concours.

Notre expérience

Sur ce blog, nous avons une longue expérience de l’Imagine Cup. Nous nous sommes connus autour de cette compétition et ça va faire maintenant presque 4 ans que nous revenons avec des équipes plus ou moins différentes, des projets qui changent ou qui se renforcent.

Je vais ici détailler notre vision de la compétition et nos objectifs pour cette année. Clignement d'œil

Pourquoi la vivre ?

L’Imagine Cup est un concours à vivre dans sa vie étudiante. Cela nous a appris énormément. Nous y avons découvert comment faire un dossier original et se démarquer des concurrents, nous avons appris à prendre la parole en public puis peu à peu à structurer un pitch, à raconter une histoire. Nous avons encore du travail sur ce point, mais je rêve d’enfin avoir une standing ovation à la fin d’une présentation !

Nous avons aussi peaufiné notre anglais à force de présenter et travailler dans cette langue. Lors de l’Imagine Cup tout se fait en effet dans la langue de Shakespeare. Nous ne parlions quasiment pas anglais lors de notre première présentation, entre temps on a pas mal évolué !

Sur la partie technique, nous avons appris à travailler en équipe, à développer des prototypes rapidement, à aller à l’essentiel à ce qui fera l’effet “Waouh”. Nous sommes aussi sortis de notre garage pour rencontrer équipes marketing et designers.

Professionnellement, l’Imagine Cup est un concours qui va vous permettre d’attester de ce genre de compétences. Mais vous ferez aussi de belles rencontres, de nouveaux amis et des contacts parmi les meilleurs.

Les projets peuvent aussi être des opportunités de création d’entreprises. Le niveau est haut (mais pas inatteignable si vous bossez) et vous pouvez déjà être sûr que votre idée est bonne si vous arrivez en finale.
Certains se sont lancés, beaucoup ont fini entrepreneurs, et certains ont fait de belles success-stories (Kobojo, Graphic Stream, sans compter ceux qui ont fini chez Microsoft !). J’ai personnellement pu porter un projet pendant quelques mois au Chili.

Et puis c’est tellement grisant d’être comme une rockstar le temps d’une finale, présenter chez Microsoft, être entouré d’un staff génial et de monter sur le podium !

Cette année

Cette année est certainement la dernière année où nous participons. Et nous comptons frapper fort Sourire.

Les catégories ont changé et la nouvelle “World Citizenship” colle parfaitement à SmartAgro que nous avions déjà proposé l’an dernier. Le projet est solide et a encore évolué ces derniers temps. Ce coup-ci nous espérons que c’est la bonne !

Une autre catégorie vient d’apparaître, “Innovation”, et c’est l’occasion de monter un projet qui nous tient à cœur depuis quelques temps : Deewile.

L’année dernière nous avons vécu différentes choses personnelles ; nos horizons, nos vies ont été bousculés, nous arrivons à une étape charnière de notre vie : la fin de nos études.

Et nous nous sommes aperçus que nous avions énormément de rêves et la possibilité de les réaliser. En sortant de notre zone de confort, sûrement, mais tout est possible. (Il y a eu aussi l’histoire de ce gars qui a sauté depuis l’espace qui nous a confirmé qu’on vivait dans un monde d’opportunités !)

Donc je disais, tout est possible… mais nous ne savons pas comment tout faire !

C’est de là qu’est venu l’idée de Deewile ! Deewile c’est une liste de choses à réaliser dans sa vie. Mais c’est une liste interactive, une liste où vous allez pouvoir ajouter des étapes, une liste qui viendra vous taper sur l’épaule pour vous dire que l’étape suivante est pas si compliquée, une liste qui va aller chercher des personnes qualifiées pour vous accompagner, une liste qui va vous mettre en condition pour trouver des rêves et la remplir.

C’est une liste qui sera partout avec vous pour que vous puissiez lui confier le moindre de vos rêves et vous en rappeler pour les réaliser.

C’est une liste des choses que vous voulez accomplir mais aussi que vous avez accomplies ! La plateforme s’occupe de recueillir vos souvenirs, vos photos, vos vidéos, vos émotions pour les mettre en forme et pourquoi pas les transmettre à votre famille, vos amis !

Deewile, c’est l’application pour que vous rêviez votre vie et que vous viviez vos rêves !

Présentation :http://sdrv.ms/11gd3Qo
Vidéo : http://sdrv.ms/11gcQfZ
Twitter : http://twitter.com/Deewile

Par JC VASSELON