Coupons de réduction Google Gsuite

Comme je l’ai dit dans mon précédent billet, j’utilise Google Gsuite, aussi bien de manière personnelle que professionnelle. On connait tous Gmail, Google Drive, Google Docs, Google Calendar, … Ils sont disponible gratuitement avec certaines limitations (la principale étant l’espace disque de “seulement” 15 GO).

Pour 4€ par utilisateur et par mois (ou 40€ par utilisateur en payant à l’année), vous passez à 30 GO de stockage par utilisateur et vous pouvez utiliser vos propres noms de domaine. C’est ce qui m’a amené à l’utiliser même pour mes besoins perso.

Je vous en parle parce que j’ai 2 coupons de réduction à vous proposer. Ils vous offrent une réduction de 20% la première année, ce qui n’est pas négligeable pour une entreprise (et toujours bon à prendre pour un particulier).

1er coupon : L9K7C3C43LNMEJF

2ème coupon : 499VR4V47LUXXM3

(Edit : ces deux coupons ont été utilisés, j’en ai mis d’autres en commentaire)

Pour utiliser ces coupons, cliquez sur ce lien : https://goo.gl/QYnpKS
Petite précision : Cette promotion n’est valable qu’en France…

Pour être complètement transparent, chaque utilisation de coupon me fait gagner 12€, soit 3 mois gratuits pour mon usage personnel. Je ne cours pas après, c’est plus pour rendre service à ceux à qui ça pourrait être utile.

L’email n’est pas mort (suite)

Il y a 4 ans, j’écrivais un article intitulé L’email n’est pas mort, dans lequel je réagissais au courant de pensée disant que la messagerie électronique était condamnée en milieu professionnel, face aux réseaux sociaux d’entreprise.

Pour faire simple, je disais que l’email est un outil parmi beaucoup d’autre (j’en listais une douzaine), et que vouloir travailler sans email est aussi intelligent que de vouloir travailler sans téléphone : il ne faut pas travailler avec ce seul outil, mais ça ne veut pas dire qu’il faut le bannir pour autant.
La force des outils universels, c’est avant tout l’usage et la pérennité dont ils bénéficient, qui sont assez difficile à prendre en défaut.

Ce qui me fait revenir là-dessus, c’est l’annonce de l’arrêt par Facebook de leur système de messagerie, qui avait été présenté en 2010 comme un « Gmail-killer » et qui n’aura finalement été qu’un pétard mouillé.

L’autre fameux tueur d’email qui n’aura pas fait long feu, c’est Google Wave. L’outil était splendide, mais difficilement utilisable au quotidien. Présenté en 2009, Google annonçait sa mort un an plus tard, pour finalement fermer le service début 2012.

Bref, que faut-il penser de tout ça ? Eh bien qu’il est difficile de remplacer quelque chose d’aussi universel que l’email. Mais plutôt que de vouloir le remplacer, je reste persuadé qu’il est beaucoup plus malin de chercher à enrichir le système, à le compléter, à s’y adosser pour aller plus loin.

Dart, NaCl, Pepper, Emscripten, PNaCl : Du nouveau du côté de la programmation sur navigateur

Comme tous ceux qui font du développement web, je code pas mal en Javascript. J’en ai déjà parlé sur ce blog, c’est un langage dont j’apprécie la souplesse mais dont les limitations m’empêchent d’imaginer faire du vrai génie logiciel dessus. J’ai beau faire des développements JS “propres”, avec l’utilisation d’objets rangés dans des namespaces hiérarchiques, je ne cesse de pester contre l’âpreté de son modèle objet.

Toutefois, pas mal de choses bougent en ce moment du côté du développement sur les navigateurs. Je n’ai pas encore vraiment mis le nez dans tous ça − à part lire de la documentation − mais ça reste intéressant d’en parler un peu.

Dart

Pour commencer, le langage Dart − créé par Google pour remplacer un jour le Javascript − vient de voir son SDK publié en version 1.0. C’est un langage qui fait voler en éclat les problèmes du Javascript ; son modèle objet est complet, il gère nativement les packages, et il peut être aussi bien fortement que faiblement typé.

Pour le moment, seule une version spécialement modifiée du navigateur Chromium (Dartium) est capable d’interpréter directement du code Dart. Mais il est possible de « compiler » du code Dart en code Javascript, permettant son exécution par n’importe quel navigateur. Là où ça devient intéressant, c’est que cette phase permet d’optimiser le code Javascript généré au point de le rendre en 42% et 130% plus rapide que le même code écrit nativement en Javascript.
C’est d’autant plus intéressant que les interpréteurs Javascript ont connu une énorme augmentation de leurs performances ces dernières années.

Bon, par contre je ne suis pas persuadé que passer par une phase de compilation pour du code client soit très pratique d’utilisation. Mais il reste toujours la possibilité de développer sur Dartium, puis de tester le code JS généré sur les autres navigateurs.

En tout cas, si le Go (l’autre langage de Google) a réussi à obtenir un peu de “traction”, j’ai le feeling que le Dart a le potentiel pour se faire une place de choix dans l’univers des langages de programmation modernes.

Programmation C/C++

Bon, quand il s’agit d’obtenir les meilleures performances possible, on finit quoi qu’il en soit par programmer en C ou en C++. Les ingénieurs de Google en étaient arrivés à cette conclusion et ont développé NaCl (pour “Native Client”) qui est une techno permettant d’exécuter dans un navigateur du code compilé pour processeur x86.
Enfin, quand on dit « dans un navigateur »… ça marche tant que le navigateur en question est Chrome, hein.

En plus, avec l’API Pepper, le code C/C++ n’est plus cantonné à une simple fenêtre, mais il peut communiquer avec le navigateur, ça peut amener à des choses sympatiques.

Mais fondamentalement, j’ai toujours trouvé cette idée bizarre. Oui, c’est génial d’avoir Quake qui tourne dans un navigateur web. Mais le principe fondamental du web, c’est de reposer sur des standards multi-plateformes. Embarquer du code compilé nativement pour un type de processeur au milieu de tout ça, c’est moche.

Ça tombe bien, car deux technologies différentes permettent de contourner ce problème. Les deux reposent sur une particularité du compilateur LLVM. Pour schématiser grossièrement, un front-end prend en charge la compréhension d’un langage de programmation, génère un bytecode spécifique, qui est ensuite utilisé par le back-end pour produire un exécutable natif. Et donc, le bytecode intermédiaire n’est pas dépendant du processeur sur lequel il va être exécuté.

La première techno basée sur ce bytecode s’appelle Emscripten. Elle prend du bytecode LLVM, et génère du code Javascript qui peut être exécuté directement par le navigateur. Le résultat est assez bluffant, dans la mesure où le moteur Unreal 3 a été porté en seulement 4 jours, et que la démo Epic Citadel qui est basée dessus est vraiment impressionnante.
En plus, avec la bibliothèque pepper.js, il est possible d’atteindre le même résultat qu’avec l’API Pepper (intégrée à NaCl, citée plus haut).

La seconde techno, issue de Google (décidément !), s’appelle PNaCl (pour Portable Native Client). Grosso modo, vous prenez NaCl, vous lui ajoutez Emscripten, vous mélangez bien, et voilà le résultat. En fait, le navigateur intègre un interpréteur de bytecode LLVM. On obtient ainsi le meilleur de chaque monde : la vitesse d’exécution qu’on est en droit d’attendre d’un code C/C++, avec la portabilité qu’on est en droit d’exiger sur le web.

Conclusion

Comme je le disais, ça bouge du côté du développement sur navigateur. Et c’est assez excitant. Je vais avoir du mal à trouver le temps d’expérimenter ces technos, mais j’en ai bien envie.

On peut remarquer que le vénérable Javascript, grâce à son support quasi-universel, reste le garant de la compatibilité de ces technologies (Dart, Emscripten) avec tous les navigateurs existants. Il devient le bytecode générique du web, un peu comme le C est utilisé par certains langages exotiques comme un bytecode intermédiaire (j’en parlais dans un article sur la création d’un interpréteur).
Pas sûr qu’il soit très simple ni rapide de faire une triple compilation (C/C++ vers bytecode LLVM, puis vers Javascript, pour enfin être interprété sur le navigateur, éventuellement avec de la compilation JIT). Mais si on peut accélérer le codage en développant sur un navigateur spécifique, pour ensuite être compatible avec tous les autres, ça peut en valoir la chandelle.

Management d’entreprise : trois exemples que tout oppose

Assez souvent, lorsque je discute de management et de gestion d’entreprise, on me dit que seule telle ou telle pratique garantit la réussite d’une entreprise ou d’un projet. Cela m’amuse, car je pense au contraire qu’il n’y a aucune recette miracle, et que chaque situation est différente.

Pour illustrer cela, j’aime prendre l’exemple de trois entreprises dont les dirigeants sont partis dans des directions clairement différentes. Ces entreprises ont connu le succès, si bien qu’on ne peut pas dire que les méthodes utilisées sont mauvaises.

Les entreprises en question sont Apple, Google et Virgin.

Apple

Tout le monde a entendu parler, ne serait-ce qu’un minimum, de la manière dont fonctionnait Apple. Sur la période 1997-2011, quand Steve Jobs en tenait les rênes, cette entreprise était l’exemple même de la centralisation de l’information : tout le monde prenait ses ordres et référait directement à une unique personne, qui fait circuler l’information comme elle le souhaite.

Cette méthode a prouvé son efficacité. Il suffit que le patron détecte une priorité pour que l’effort de l’entreprise soit très rapidement dirigé là où il le faut. Si le big boss a le soucis du détail, cela façonnera la culture d’entreprise, et les produits qui sortiront seront exemplaires.

On connait aussi les inconvénients. Une seule personne peut difficilement gérer tous les aspects d’une entreprise, surtout lorsque le nombre de ses produits et de ses services augmentent. Et même si les fanboys me contrediront, tout ce qu’a sorti Apple n’était pas d’égale qualité (MobileMe, Apple TV 1ère génération, iBook 2ème génération, certains iPod, …). Sans parler des lubies que l’entreprise peut se voir imposer sans d’autre choix que de les subir.

Google

Plusieurs livres ont été publié dans les années 2000, à propos de la « Méthode Google », pionnière du « Management 2.0 ». Un des points les plus intéressants était l’influence du milieu universitaire : les créateurs de Google − Larry Page et Sergueï Brin − étaient des chercheurs, alors ils embauchaient des chercheurs. Pendant très longtemps, il fallait un doctorat pour y être recruté. L’équation semble couler de source ; les personnes qui ont fait de la recherche ont l’habitude de travailler seules, tout en étant très productives.

Cela a amené à un système très décentralisé, constitué d’un grand nombre d’individualités qui interagissent ensemble. Chaque personne ayant ses projets et ses objectifs, le résultat peut être impressionnant d’efficacité. C’est d’ailleurs ce modèle qui a permis à Google de développer un grand nombre de ses services (Gmail, Reader, …).

Le revers de la médaille, c’est que l’entreprise peut se transformer en monstre sans tête, en perpétuel mouvement mais sans direction coordonnée. Pendant longtemps, on entendait parler de services pour lesquels le manque d’interlocuteur clair était un frein.

Un autre inconvénient apparaît lorsque − comme Google − l’entreprise grossit tellement qu’elle est obligée de revoir ses critères. Cela fait bien longtemps que Google ne recrute plus uniquement des docteurs. Et même si les méthodes de management ont dû s’adapter à cela, on peut imaginer aisément que l’organisation générale s’en est retrouvée profondément modifiée.

Virgin

Il y a plusieurs années, j’ai vu à la télévision un reportage sur Virgin et son créateur, Richard Branson. Et même si je ne me souviens plus bien du contenu du reportage, il y a un détail qui m’avait marqué. À l’époque où Virgin était principalement une maison de disques (avant qu’elle ne devienne une marque de cola, de transport aérien et ferroviaire, de téléphonie mobile ou encore de tourisme spatial), Richard Branson avait mis en place une organisation très originale.

Virgin n’était pas une unique entreprise ; c’était une constellation de petites compagnies. Dès que l’une de ces unités dépassait un certain nombre de personnes (une vingtaine, dans mon souvenir, mais je peux me tromper), il la scindait en deux.
Son principe était qu’une petite entreprise est toujours plus efficace, productive et réactive  qu’une grosse société. Et partant de là, il faisait en sorte que toutes ces petites entreprises aient chacune des objectifs financiers propres, devenant cliente et fournisseur les unes des autres. Un peu comme si chaque groupe de projet devenait une entité business autonome.

Je suis assez d’accord sur le principe ; on voit plus d’innovation dans les start-ups que dans les multinationales, et une petite équipe sera toujours plus efficace qu’une grosse. C’était de l’agilité avant l’heure, appliquée au niveau de l’entreprise.

Il y a forcément des inconvénients à ce modèle, mais c’est celui qui est le moins bien connu. Je peux imaginer qu’il soit difficile de maintenir un équilibre cohérent à une telle myriade de TPE, et qu’on risque de se retrouver avec à la fois les faiblesses structurelles des start-ups  et les lourdeurs d’une grande société.

Au final

Tout ça pour dire qu’il n’existe pas une unique vérité. Je suis persuadé que chacune de ces méthodes n’aurait pas pu fonctionner dans d’autres circonstances. C’est dans ces conditions que les créateurs de ces entreprises se sentaient à l’aise ; ils ont donc bâti leurs empires sur ces bases, en mettant en place ce qu’il fallait pour que les choses fonctionnent comme ils le désiraient.

Si on se réfère à d’autres types de modèles, on pourrait dire qu’Apple est une monarchie, Google est un anarchie, alors que Virgin est une fédération (au sens fédéralisme ou confédération).
Je ne veux pas faire de politique, donc je ne dirais pas si un modèle est meilleur que les autres à mes yeux. Par contre, ce que je remarque, c’est que ce sont trois méthodes de management atypiques, mises en œuvre dans trois entreprises d’exception.

Et on en revient à mon message habituel : Imprégnez-vous de ces exemples, approfondissez-les si vous le souhaitez, mais n’essayez pas de les appliquer tels quels dans votre propre entreprise. Vous n’êtes pas Jobs,  Page/Brin ou Branson ; ça ne fonctionnera pas.