J'avais été passionné par la visite de Facebook, Apple et PayPal (eBay) que
j'ai eu la chance de faire l'été dernier, ainsi que celle d'autres
nouvelles stars montantes de la Silicon Valley. J'en ai retenu une approche différente de la DSI pour l'informatique interne. Beaucoup plus à l'écoute des salariés, le BYOD est une règle et un SI totalement aligné avec la philosophie générale de l'entreprise: Un SI intégré au "Facebook interne" pour Facebook, un SI à l'interface totalement re-écrite et prônant la simplicité (apparente) pour Apple. Presque un cliché. Voir "DSI de Facebook, un poste avancé de la transformation des DSI"
C'est donc avec plaisir que j'ai lu l'ouvrage collaboratif publié par Octo Technology sur les "Géants du Web" qui nous entraine, entre autres, dans les méandres des plateformes technologiques de LinkedIn, Netflix, Google et Amazon. Où on y découvre une approche totalement différente des problématiques informatiques, tellement ce qu'ils cherchent à faire est nouveau et que leur besoin de scalabilité à l'échelle du Web, les amène à imaginer de nouvelles solutions. Eh oui, tout le monde ne compte pas ses clients par paquets de 100 millions..
Un passage de cet ouvrage qui m'a particulièrement marqué c'est le "Build vs Buy". C'est à dire vaut-il mieux fabriquer (développement spécifique) ou acheter (progiciel). La sempiternelle question à laquelle tout DSI est exposé à chaque nouveau besoin des métiers.
Les services informatiques ont commencé dans les années 80 par répondre "Build", avec du développement en Cobol souvent. Mais en 2013, la majorité les DSI vont répondre "Buy" tellement elles ont été échaudées par des développements spécifiques non maîtrisés. Parfois parce que les métiers n'arrivent tout simplement pas à les spécifier totalement, d'autres parce que cela semblait simple à coder au départ, et surtout parce que finalement ils coûtent cher à maintenir.
Et donc aujourd'hui, la DSI se rassure avec la sécurité des progiciels pour tout ce qui ne concerne pas le cœur métier (en supposant qu'il soit bien cerné...). Des progiciels, qui cela dit en passant, échouent parfois aussi et qui savent s'entourer de paillettes pour nous séduire et faire oublier leurs échecs.
Mais pour les géants du web ou les fragiles startups, l'informatique "EST" le cœur métier.
Car sans informatique plus rien ne marche. De la commande à la livraison, de l’appât du client détecté sur un site grâce à son tracking permanent jusqu'à l'achat. Et même parfois le produit lui-même qu'il achète est numérique (un film à la demande) ou dérivé du numérique (un clic sur une page de pub). Ne cherchez donc pas de progiciels dans le cœur des systèmes industriels de ces entreprises numériques. En 2013 un géant du web va répondre "Buid" sans aucun doute à la question précédente. D'autant plus que cela lui amène une maîtrise totale du code, sans royalties ou risque sur la propriété intellectuelle finale de sa solution.
Et certains de ces géants vont même jusqu’à supprimer ce qu'une DSI ne remettrait jamais en cause, tellement c'est le socle de tout (y compris de son mode de pensée): par exemple une base de données du marché dans le cas de LinkedIn. Ne la cherchez plus ils ont re-développé à la maison, plus rapide, plus fiable, pour leur plateforme mondiale.
Et d'ailleurs Jean Marc Potdevin, COO chez Viadeo notre champion national, confiait en novembre dernier lors d'une conférence, suivre Hadoop et GraphDataBase de très près pour gérer l'analyse de ses 45 millions de membres.
Le "Build" est donc la règle sur cette magnifique chaussée des géants.
Mais la culture open source et l'adoption massive des frameworks open source est pour ces géants un moyen de ne pas réinventer le fil à couper le beurre. Et surtout de rejoindre ou de créer un réseau de d'experts et de ressources techniques sur ces nouvelles solutions. Car l'argument ultime d'une DSI pour les progiciels, qui par construction (et par expérience) a horreur du risque, c'est "en cas de problème je peux me retourner vers l'éditeur". Vous l'avez déjà entendu celle-là?!
Et bien, sauf que comme le fait justement remarquer cet ouvrage, combien de problèmes techniques dans les DSI sont résolus par l'éditeur (dont les consultants sont payés parfois jusqu'au triple du prix d'une ressource de SSII) et combien par des forums et un réseau d'entraide sur la toile? Et bien beaucoup moins qu'on ne l'imagine...
Les géants du web ont adopté un modèle prônant l'ouverture et la force de l’écosystème.
Et ces nouvelles solutions sont architecturées et pensées dès le départ pour supporter le web. C'est peut-être une des raisons pour laquelle les solutions autour du "big data" comme Hadoop viennent de ces sociétés et non des éditeurs traditionnels.
Alors faut-il renoncer aux progiciels et se préparer à un retour du développement spécifique dans les DSI? Faut-il transformer nos DSI en éditeurs de logiciels sur mesure finalement?
Les SSII ont essayé de prendre ce rôle ces 20 dernières années, en sous-traitance des DSI, avec plus ou moins de succès. Plutôt moins quand la gestion des compétences et des talents n'était pas leur fort, et que la qualité du code était dans le meilleur des cas, moyenne. Car généré par des ateliers logiciels génériques et "bavards" ou produits par de jeunes recrues talentueuses... mais ne maîtrisant pas le framework du projet. Heureusement, certaines SSII ont compris que la qualité des développements était aujourd'hui une force et que l'architecture était une fondation. Et les outils d'analyse de code sont remis au goût du jour et certains passent en SaaS. Alors ne vous étonnez pas de voir ces sociétés moins connues se développer à l'avenir et d'autres acteurs historiques plus connus disparaître.
Quand on est sur un besoin commun à plusieurs entreprises, le progiciel reste bien sûr très adapté. A condition de respecter la sacrosainte règle de ne pas le modifier ou d'isoler proprement le spécifique. Mais l'éclairage des géants du web met en évidence deux nouvelles situations pour rompre avec l'approche progiciels :
-
quand c'est une brique différenciante et que celui qui a cette fonction en tire un avantage pour son business modèle.
Et notamment quand le modèle lui-même est numérique. C'est vrai pour
des systèmes intelligents, codant des algorithmes uniques, ou
automatisant un processus totalement repensé et nouveau exploitant la
technologie (la rupture ZipCar par exemple :article )
-
quand il y a une opportunité de développer un produit utilisable par l'entreprise, mais aussi commercialisable
auprès d'autres entreprises car ses fonctionnalités sectorielles sont
pertinentes pour de petits acteurs de l'industrie qui ne peuvent les
développer. Et dans ce cas, le SaaS est un modèle intéressant et déjà exploré par ces géants du web. C'est l'opportunité pour l'entreprise d'utiliser son SI pour la construction d'un ecosystème autour de problématiques sectorielles,
en pouvant choisir qui y faire rentrer. La différenciation se fait par
l'écosystème et non uniquement par la fonction. C'est une sorte
d'adaptation du modèle open source au niveau logiciel métier spécialisé.
Cas pratique: vous
voulez commercialiser une chaussure de sport bourrée de capteurs qui
enregistrent tous les mouvements du corps et le pouls de celui qui
l'utilise? Tout ça pour lui donner un tableau de bord de ses
entrainements et des conseils sportifs quotidiens, voir lui préconiser
un régime alimentaire?
Vous êtes certainement dans la différenciation par rapport à vos concurrents vendeurs de baskets à fleurs!
Le développement spécifique semble donc adapté, foncez!
Et même, le cœur de votre système, la base de données pour
l'enregistrement des mouvements, est certainement un module qui peut
intéresser tout un écosystème via vos API. Pour qu'ils puissent les
croiser avec leurs données et apporter plus de valeur à l'utilisateur.
Alors clairement oubliez SAP, Microsoft Dynamics et les autres,
peut-être même les bases de données Oracle ou DB2 et relisez Linux,
MySQL et Java ou PHP pour les nuls.
C'est visiblement comme cela que la frêle start-up aurait pris le problème... avant de devenir un géant du web.
