Tout d'abord. Je précise que ce billet n'est que le fruit d'une réflexion personnelle et basé sur les discussions que j'ai pu avoir avec des personnes travaillant chez Google. Je ne peux garantir à 100% la véracité de mes propos. Aussi cette discussion sera principalement basée sur Google Apps pour les entreprises, le cas des particuliers sera discuté très rapidement en fin de l'article.

Le premier argument qui revient à l'opposition d'opter pour la solution Google Apps est la gestion des données. En effet, comme tout service de type SaaS (Software as a Service), tout est hébergé chez Google, vos mails, vos documents, tout. Et c'est normal quand on est du milieu professionnel (c'est aussi valable pour le milieu personnel bien sur) de se poser des questions sur la gestion de ses propres données chez Google. En effet dans le milieu professionnel, on peut rapidement avoir des informations très importantes et confidentielles qui circulent par mail ou dans des documents. Contrairement aux structures habituelles qui permettent de poser des limites comme par exemple l'accessibilité de vos mails seulement via un intranet et par internet via un protocole lourd et complexe nécessitant 50 identifications (quand l'entreprise met ça en place, ce qui n'est pas le cas partout, croyez-moi), avec Google Apps, et c'est un des arguments de ventes, vous accédez simplement à vos mails qu'importent ou vous êtes et en toute sécurité.



Forcement, il y a des secteurs et des entreprises qui par conséquent ne peuvent choisir cette solution, car nécessitant un niveau de sécurité très supérieur à la normale, et ce n'est pas le cœur de cible de Google Apps. Mais pour les autres, Google doit forcement s'engager car il est hors de question que des données stockées via Google Apps soient facilement accessibles. De
plus, il est bon de noter que Google, comme toute entreprise basée aux Etats-Unis est soumise au Patriot Act, qui permet aux services des renseignements américains de réclamer et de récupérer sans que l'entreprise puisse broncher les données qu'elle souhaite pour des besoins d'enquêtes etc (qui a dit espionnage industriel ?). Google s'est déjà permis à plusieurs reprises de refuser de donner ses données et est actuellement en train de mettre en place différentes solutions lui permettant de passer outre ce Patriot Act pour tous les utilisateurs de ces services en dehors des Etats-Unis.

A ce niveau là, il est normal de penser qu'il n'y a donc aucun intérêt à utiliser la suite Google Apps. Je vais donc citer quelques arguments qui font l'intérêt de cette solution. Bien sur, on ne peut pas dire que Google Apps est le produit idéal pour toutes les entreprises, tout comme on ne peut pas dire que c'est la pire solution existante.

Contrairement à un hébergement classique des informations (au sein par exemple d'un seul serveur), ici l'information est stockée partout et plusieurs fois. Qu'est ce que ça signifie ? S il existe une faille sur votre serveur. Une personne malintentionnée peut alors tout récupérer. Avec les produits Google, elle ne sera en mesure de récupérer qu'un morceau de l'information car les informations sont stockés sur différents Datacenter, elles sont dupliquées à différents endroits. Il est beaucoup plus compliqué de retrouvé une information contrairement à une solution de stockage sur un Datacenter précis (attention bien sur, si on vole les accès d'un compte, c'est une autre histoire - que ça soit pour la solution Google ou non)

Les applications de Google sont déjà mises à rude épreuve tous les jours, qui ne rêvent pas de publier LA faille de sécurité sur un produit Google ? Par conséquent si le système était non sécurisé on serait rapidement au courant. Et je ne parle pas de la réactivité et de l'efficacité des développeurs chez Google qui n'est plus à prouver.

Enfin, bien sur, on peut se dire que la faille se situe au niveau de Google tout simplement. Et si Google décide d'accéder à vos données et de les fournir à un tiers ? Mais il faut faire preuve de bon sens pour comprendre certains points. Google souhaite s'implanter sur le long terme au sein des entreprises avec Google Apps ce qui n'est pas du tout le cas pour le moment. Ils n'ont strictement AUCUN intérêt à faire ce genre de choses, aussi découvert (et ça ne mettrait pas longtemps), Google aurait une tel mauvaise pub que le marché des entreprises leur serait fermé. Et quand on sait que le marché des pubs sur internet arrive à saturation – et puis Google devra bien trouver un autre moyen pour continuer sa progression - Google n'a vraiment aucun intérêt à se tirer une balle dans le pied. Aucun intérêt.

Et pour les particuliers, il faut savoir qu'en Europe Google a déjà baissé la durée de stockage d'informations privées (sur les recherches) à 18 mois bien que la CNIL et ses équivalents Européens demande encore une baisse à 6 mois. La demande est compréhensible, mais d'un point de vue développeur, je comprends aussi qu'il soit important de stocker certaines informations afin d'améliorer par la suite les algorithmes de recherche. Enfin il y a une derrière chose, on a souvent peur de stocker toutes nos informations chez Google. Peur de se dire qu'ils possèdent toutes nos données, alors on préfère en semer un peu partout et c'est compréhensible.

Bien sur, il y a un facteur de poids qui doit jouer dans une décision comme celle de choisir Google Apps pour son entreprise ou bien de stocker toutes ses données sur les différents services de Google : c'est la confiance, et Google le sait :

« Nous reconnaissons que la confiance de l'utilisateur est un élément-clé de notre activité [...]» Nicole Wong - Avocat général de Google.

Le 8 Avril dernier, Google a lancé son nouveau service, Google AppEngine. Ce service a pour but de vous proposer une solution d'hébergement pour vos applications web. L'avantage d'AppEngine se situe au niveau de la scalabilité (capacité d'un système à évoluer en puissance) de votre architecture web. Pour que vous compreniez mieux, voici un petit exemple. Imaginez que vous développiez une petite application web dans votre coin. Vous êtes une dizaine de personne à vous en servir et vous avez donc un serveur qui est calibré pour ce nombre d'utilisateurs. Du jour au lendemain, un site populaire fait une news sur votre système, ou votre site est "diggué" et donc par conséquent le trafic augmente brutalement. Votre serveur va se retrouver dans les choux et les utilisateurs ne manqueront pas de lâcher un "bouh c'est nul ça marche pas de toute façon". Avec AppEngine, votre architecture web s'adapte à vos besoins (à votre trafic donc), votre serveur devrait donc tenir la charge sans soucis.

Voilà pour la théorie, en pratique, le service vient d'être lancé et il est encore très limité, la partie payante du service n'a pas encore été dévoilé. Pour le moment chaque développeur bénéficie de 500Mo de stockage pour son application et de 5 millions de pages vues par mois. Le dépassement de ces limites entraînera une charge financière pour le développeur mais pour le moment cela bloque juste l'accès à l'application. Je ne m'attarderais donc pas sur ce point. Je vais plutôt vous parler du coté technique.



Un des premiers points négatif tombe directement. Un seul langage supporté (pour le moment). Le Python. Les développeurs PHP, RoR et autres sont donc dans l'impossibilité de déposer leurs applications existantes. Il en est de même pour le système de base de données. Pas de MySQL ou autres, un seul système, BigTable, système interne créé par Google pour leur besoin. On est donc dans l'obligation de se mettre au Python si l'on souhaite créer son application web, forcement l'accessibilité aux services en est réduite. On a donc un premier frein qui va rebuter pas mal de développeur malgré le fait que le Python soit un langage assez simple à comprendre et à utiliser.

A l'ouverture de ce service, je n'ai pas pu récupérer une des 10000 premières invitations. Je me suis donc contenter de récupérer le SDK AppEngine qui permet de travailler en local. Comme d'habitude, Google fait bien les choses puisqu'une doc complète et des tutoriaux viennent illustrer le SDK et ses quelques APIs. On se retrouve très vite avec un "Hello World" qui tourne sur son serveur local. Le principe est très simple. On dispose de deux exécutables pour uploader sur l'AppEngine ainsi que pour tester en local en lançant un serveur web très rapidement.

Après avoir testé un peu plus en profondeur de mon côté, voilà ce que l'on peut reprocher à l'AppEngine :


* Les timezones : Toutes les dates et heures sont basées sur l'heure UTC. Par conséquent il faut insérer des traitements supplémentaires pour recaler les dates et heures au timezone français par exemple. C’est un traitement qui alourdit le temps d’exécution.

* Backup de BDD : Il n'est pas possible à ma connaissance de récupérer un back-up de sa base de données en ligne. On ne peut donc pas non plus faire des traitements de masses sur sa base, si par exemple on souhaite modifier la structure ou faire un import de masse sans passer par l'application web.

* Exécution de tache à heure fixe (CRON par exemple) : La encore on ne peut pas programmer des traitements à heure fixe. Bon ce n'est pas un souci pour la majorité des gens et ça n'est pas dispo' sur la majorité des serveurs web de base non plus.

* Une BDD un peu lente : Quand on commence à pousser un peu niveau requêtes/analyses sur la base (récupérer plus de 2000 lignes par exemple). On se rend compte que BigTable galère un peu et c'est bien dommage.

* Gestion des données en base complexe : Les IDs de lignes ne sont pas accessibles, on est obligé de récupérer l'id après un insert pour ensuite mettre à jour sa colonne perso ID avec le même. Ce qui fait qu'on se retrouve avec deux colonnes représentant la même information, une accessible seulement par BigTable et une autre identique fait par nos soins. D'un fait général, s'aventurer vers une base de données avancée me parait dès lors très complexe.


Mais il ne faut pas oublier que l'AppEngine est tout jeune et comme tout produit Google il est voué à évoluer très rapidement. Les développeurs parlent déjà de supporter plus de langages (ce qui n’est pas forcement une bonne nouvelle, je préfère personnellement cent fois le Python au PHP). Il n'est pas destiné à n'importe qui, mais il offre quelques avantages non négligeables. Comme par exemple l'intégration du SSO Google via l'API. C'est à dire que l'utilisateur s'identifiera avec son compte Google pour se loguer à votre application, en contrepartie vous accéderez à son email, login et autres infos du compte (pas tout bien entendu) alors que vous auriez du coder tout ça -compte et sa gestion- par vous même auparavant.

Il faut donc laisser du temps à l'AppEngine pour murir un peu. Mais nul doute que le produit est intéressant, en particulier si son intégration à Google Apps est possible.

Et vous, vous avez testé ? Ça vous inspire quoi ? Ça vous passe au dessus du cigare ?

Aujourd'hui je vais vous parler des librairies JavaScript. Tout bon informaticien qui se respecte est un gros fainéant qui a encore des morceaux de chips bolognaise dans sa barbe, composée de poils durs mais aussi de ceux de la puberté, vous savez, ceux qu'on a jamais vraiment voulu couper. Bref, il est tout à fait normal de ne pas vouloir refaire ce que des personnes ont déjà codé. C'est un fait (si bien sur ça ne vous apporte rien de plus qu'une perte de temps). Il arrive donc fréquemment lors de la conception d'un site Internet que l'on souhaite intégrer une fonctionnalité qui nous parait cool (en ce moment, il y a souvent le mot Ajax/Web2 qui traine a coté du nom de cette fonctionnalité) mais qui est franchement casse-couille à mettre en place. Heureusement pour vous, des librairies JavaScript sont là pour vous faire gagner un temps fou.

Elles ont pour but de vous faciliter la vie avec le JavaScript qui est par défaut un langage vraiment indigeste. Elles vous permettront avec une syntaxe facile et surtout en étant cross-browser (c'est à dire que le code produit le même résultat sur tous les navigateurs) de gérer vos pages HTML. Elles permettent d'accéder facilement à des éléments div, tableau, etc et entre autres d'y appliquer des effets pour les afficher, cacher, faire glisser de droite à gauche ou encore de les faire disparaitre avec un fondu des plus coquet. On peut aussi utiliser les fonctions d'XMLHttpRequest plus connu sous le doux nom d'Ajax pour pouvoir modifier votre page en interogeant des pages distances sans recharger toute votre page. Elles permettent aussi d'utiliser pas mal de fonctions qui vous faciliteront la tache tout au long de vos développements JavaScript. De quoi vous évitez beaucoup de boulot. Reste à décider lequel choisir.



jQuery (site officiel) : Surement le plus populaire. Il est facile à prendre en main et une des fonctionnalités que j'apprécie énormément c'est la possibilité d'enchainer les fonctions. Tester certaines fonctions ici mais la page et les démos ne montrent pas vraiment toutes les possibilités de ce framework.

Prototype (site officiel) : Très connu lui aussi et traine souvent avec script.aculo.us. C'est d'ailleurs son principal intérêt car il est à mon gout un peu moins bien que jQuery bien que mieux commenté. On se retrouve vite à faire en plusieurs lignes ce qu'on aurait fait en une seule avec jQuery. Vous pouvez voir des démos ici.

Mootools (site officiel) : Celui que j'utilise en ce moment. Je l'ai rajouté aussi sur Carrefour.fr par exemple, c'est un peu mon petit protégé du moment. Il dispose de très jolies animations, et possède une doc' agréable à lire et plutôt complète. De nombreux exemple sont disponible ici.

Dojo (site officiel) : je vous parle de celui là mais je ne l'ai pas encore testé. Il semble disposer d'énormément de fonctionnalité (mail, fisheye, etc) et à première vue dispose d'une documentation assez impressionnante. Par ici pour les démos.

Voilà, je n'ai pas parlé de Yahoo User Interface Librairy (YUI) que je ne connais pas du tout, ni de plusieurs autres frameworks. Bien sur la question que vous devez vous poser (si tout cela vous intéresse) c'est "lequel dois-je choisir ?" Et bien il n'y a pas vraiment de réponse. Certains framework sont plus rapide que d'autres. Certains offrent des fonctionnalités plus exotiques. C'est à vous de vous faire votre idée en fonction de vos besoins !