Exodus est le nom de code que je donne à un processus de grammatisation dans lequel toutes les entreprises sont engagées, qu’elles en aient conscience ou non.
De quelle exode s’agit-il ?



Il s’agit de l’exode des données des systèmes d’information legacy vers le web. C’est la migration des données, non pas de telle application vers telle autre application, mais des applications vers le web.
Le web est la plateforme dit-on. Mieux que çà, le web est le milieu, l’environnement dans lequel des plateformes commencent à se constituer. La tendance majeure, qui correspond à un vrai changement de paradigme, c’est d’avoir les données sur web. Nous allons vers un web of data :

  • avec le web 2.0, ce sont les données fournies par les utilisateurs qui ont commencé à migrer sur le web ; une toute nouvelle économie est naît, bousculant la plupart des acteurs économiques traditionnels.
  • avec le SaaS, pour les entreprises, ce sont des données de l’entreprise qui sont sur le web : data on the web. Et tout les éditeurs traditionnels de logiciels doivent faire en ce moment des choix cruciaux, quand ce n’est pas déjà fait).

La référence biblique à l’Exode est bien évidemment voulue, mais c’est ici une version moderne, technologique, industrielle et économique qui se joue.

Au départ, et pour les systèmes d’information des entreprises, il y a donc les “dix plaies de l’égypte” :

  1. Des systèmes dont les coûts de maintenance deviennent insupportables.
  2. L’incapacité à provoquer des échanges et des partages : quand les données ne se mélangent pas, les pratiques ne peuvent pas suivre.
  3. Des projets pharaoniques qui explosent les budgets et qui, pour une majorité d’entre eux, n’aboutissent jamais, ou accouchent d’une souris.
  4. Une frustration croissante des utilisateurs internes qui se demandent “pourquoi à la maison avec les service web 2.0 c’est si simple” ?
  5. Des contraintes à n’en plus finir où, pour être compliant, il faudrait ne jamais se logger au SI de l’entreprise.
  6. L’accès à l’information qui relève plus de l’archéologie que d’une “user expérience” apportée par les services 2.0.
  7. Des prestations de codage et de recodage des tuyaux entre des applications qui n’utilisent pas la même sémantique
  8. Des fuites de l’information avec des salariés qui utilisent des solutions web hors du système d’information, mais avec des données de l’entreprise.
  9. Des données difficilement accessibles en situation de mobilité.
  10. Une perte d’intérêt et de motivation généralisée dans l’utilisation du système d’information, alors même que les ressources humaines s’éfforcent de trouver des leviers pour redonner de la motivation aux salariés.

Puis virent les 10 commandements :

  1. La simplicité toujours tu choisiras
  2. L’hébergement des données n’est pas ton métier, toujours tu étudieras l’opportunité de faire héberger tes données par un tiers.
  3. La visibilité budgétaire tu privilégieras, et seul le coût d’usage et par utilisateur tu mesureras.
  4. Ne réinvente pas ce qui est déjà fait et qui est proposé par un acteur bénéficiant des coûts induits par une économie d’échelle.
  5. L’information est un capital, et comme tout capital il doit circuler ; jamais dans des bases de données propriétaires tu ne les enfouiras. Tu passeras de la logique applicative à la logique informationnelle.
  6. Les clés de ton système d’information à un ERP jamais tu ne confieras.
  7. De la tentation d’architecture de service en SOAP tu te méfieras, car les architecture REST seules sont réalistes et scalables.
  8. Des solutions grand public tu te rapprocheras le plus.
  9. Le web est la plateforme des plateformes, et sur elle tu construira ton système d’information.
  10. Les données sont faites pour être échangées, combinées : vers des mashups de données structurées tu t’engageras, et sur les APIs tu seras vigilant.

Une exode, ce n’est pas un “switch”, et ce n’est pas en un claquement de doigt que cela se fait. Il faut scanner l’ensemble de ses processus (IT, fonctionnels, métiers) et, pour chacun d’eux, identifier les opportunités (financières et fonctionnelles) de basculer les données sur le web.

Quand je dis “sur le web”, cela veut dire en conformité avec l’architecture du web. Cela peut être un intranet en interne, en hébergement externe ou directement sur le web dans les data center d’une solution SaaS (software as a Service).
Ce qu’il faut c’est :

  • S’assurer que les architectures soient full web (et pas seulement webisées pour faire de l’affichage en html)
  • Les services doivent être les plus simples et unitaires possibles : comme me le faisait remarquer Louis Naugès, si un service de gestion RH (en mode SaaS par exemple) propose en même temps un service de calendrier, et bien ce n’est pas bon. Vous en avez déjà un, Google Calendar par exemple, donc demandez à ce que cette fonction soit déconnectée du service. Vous devez maîtriser l’unité des services web et ne pas vous la laisser imposer.
  • Vous vous souvenez de ces ERP qui valorisaient l’intégration des services, le tout intégré ? Et bien là, c’est le tout désintégré. Chaque service ne doit faire que ce qu’on lui demande, posséder de bonnes APIs, en mode REST (puisqu’on sait que si les APIs sont ce que les DRM sont à la musique, alors les APIs Restfull sont les les “mp3” des APIs).

Dernier point ; lorsque l’on parle de Software as a Service (SaaS) il faut faire des distinctions car, la nuit, “tous les SaaS sont gris”.

En apparence, tout est SaaS : Google doc, Facebook, Salesforce, etc. Ce n’est que lorsqu’on se place du point de vue du programmeur que des distinctions éclairantes apparaissent. C’est ce qu’a mis en lumière Marc Andreessen en distinguant trois niveaux de “plateformes” web.

Appliqué au SaaS, cela donne :
1. SaaS d’accès en lecture et écriture -> Accès aux données (Google, eBay, Flickr)
Ce niveau 1 du Saas vous offre un SDK pour travailler avec les données via les APIs

2. SaaS de plugin -> Accès aux fonctionnalités (facebook)
Ce niveau 2 du SaaS vous offre un SDK pour réaliser des Plugins qui introduisent des fonctionnalités dans une offre SaaS et vous offre une audience (en contre partie, comme le signalait Aurélien, vous travaillez à la constitution du graphe social).

3. Platform as a service (PAAS) -> Accès à la plateforme (SalesForce, Amazon avec EC2 et S3)
Ce niveau 3 du SaaS vous offre un SDK une réelle plateforme qui héberge et fait tourner votre code.

Exodus est donc un programme planétaire qui vise à migrer les données sur la terre promise qu’est l’architecture web. Le web étant alors compris comme une gigantesque base de données.

C’est un processus de grammatisation car il discrétise les services, les simplifie et nous fait reconsidérer toute notre grammaire du numérique, c’est à dire aussi celle de nos/vos usages.