La boîte à idées - Le blog de Jean Chambard

Paris, le 14 août 2019

Retracer les évolutions des Système d'Information (SI) est un exercice des plus classiques. Tous les cabinets de conseil dignes de ce nom pourront vous en parler. Alors dans ce petit billet, j'ai essayé de faire différemment : j'ai fait tenir cette évolution dans une seule figure.

C'est donc forcément une analyse très macroscopique. Mais cela permet de voir d'où on vient et vers où on va en matière de SI.

Une évolution en trois phases

J'ai pour ma part identifié à ce jour trois grandes phases d'évolution du SI. A l'intérieur de chaque phase, on trouvera des évolutions structurantes bien sûr, mais qui n'ont pas fondamentalement changé la façon dont le SI fonctionnait.

1 ^ère phase : le SI propriétaire

Chaque entreprise, pour répondre à ses besoins, a développé ses applications et construit, brique fonctionnelle par brique fonctionnelle et serveur par serveur, son Système d'Information.

Chaque SI s'est bien sûr construit sur la base des technologies existantes de son époque. Dans les années 70, le langage de programmation Cobol  et les mainframes dominaient, que ce soit ceux d'IBM, Unisys, Fujitsu, HP ou même Bull et son système d'exploitation GCOS.

Dans les années 90, les serveurs Unix ont pris le pas, et on a commencé à voir d'autres architectures apparaître : le client-serveur (que l'on a appelé rétrospectivement architecture 2-tiers) puis les architectures Web de type 3-tiers et n-tiers poussées par l'avènement d'Internet et l'apparition des langages de programmation Java et C#.

Passer des architectures monolithiques mainframe au client-serveur puis aux architectures n-tiers a demandé de très grosses évolutions technologiques. Mais cela n'a pas fondamentalement changé la façon dont on pensait le Système d'Information. Le SI était avant tout composé d'applications développées en interne avec peu d'interaction avec les autres systèmes.

2 ^ème phase : le SI intégré

Le passage à l'an 2000 a fait peur à tout le monde ; A tout le moins à ceux qui utilisaient l'informatique dans leur vie quotidienne. La plupart des programmes n'utilisaient alors que des dates codées sur 2 chiffres. Il a donc fallu, pour ceux qui s'en souviennent encore, engager des travaux de modernisation du SI. C'est alors que les progiciels et notamment les ERP (Enterprise Resource Planning ou Progiciel de Gestion Intégré en bon français) ont commencé à prendre une place prédominante, en remplaçant les vieux logiciels obsolètes dépassés par l'an 2000.

Il a donc fallu intégrer ces progiciels au reste du SI. Avec des applications désormais distribuées sur différents serveurs. Voire sur des serveurs virtualisés (VM). On a donc inventé des solutions comme l'EAI (Enterprise Application Integration) puis quand les interfaces Web se sont généralisées l'ESB (Enterprise Service Bus).

Et avec des interfaces Web et un réseau Internet plus fiable, on s'est aperçu qu'on pouvait faire de l'EDI  (Echange de Données Informatisé) pour beaucoup moins cher et plus rapidement. On a donc commencé à intégrer les WebServices d'autres partenaires ou fournisseurs à son propre SI.

Plutôt que de développer des applications propriétaires, on a donc conçu le SI en pensant ses interfaces, ces fameuses API (Application Program Interface), permettant de communiquer tant en interne, entre le front office et le back office, qu'en externe avec d'autres SI. Avec en point central, la gestion de ces API : l'API Management, et un protocole simple : REST (REpresentational State Transfer).

3 ^ème phase : le SI hybride 

Créer des API pour permettre à ses applications de communiquer, c'est bien. Mais généraliser les API à tout son SI, c'est encore mieux. C'est ce qui a donné naissance au Cloud et à l'automatisation d'un grand nombre d'opérations. Désormais, on ne gère plus son infrastructure par ses composants, mais par du code.

Le Cloud Public a-t-il pour autant changé notre façon de concevoir le SI ?

La réponse est non si l'on utilise le Cloud en mode IaaS (Infrastructure as a Service). Dans ce mode, l'entreprise loue des machines virtuels (VM) à son fournisseur et vient simplement installer ses applications dessus. Elle y gagne en souplesse, mais la location à long terme peut lui revenir plus cher que l'achat de serveurs en propre. Faire des économies avec le IaaS demande une gestion fine de sa capacité : il faut savoir couper les serveurs inutilisés (la nuit par exemple) et n'allouer des ressources qu'en cas de demande forte.

NB : Le mode PaaS (Platform as a Service) s'avère économiquement plus intéressant car il permet à l'entreprise de s'affranchir de toute la maintenance de la pile logiciel et du middleware, prise en charge par le fournisseur de Cloud. Mais il demande un peu de discipline car il faut naturellement que vos applications suivent les montées de version du fournisseur.

La réponse est oui si l'on commence à concevoir son SI en terme de progiciels loués en mode SaaS (Software as a Service), de micro-services, de conteneurs et d'application serverless (sans serveur).  Tout en intégrant un maximum de services de son fournisseur, comme le Machine Learning, le BigData, la BlockChain, etc., et en veillant à ne pas créer trop d'adhérence entre son fournisseur et son SI.

Concevoir son SI n'est plus une histoire d'intégration de progiciels et d'API. Il s'agit plutôt d'intégrer des applications en mode SaaS avec ses propres applications, conçues en mode micro-services et Serverless. Ce terme barbare ne signifie pas que le serveur a disparu. Non, les ressources sont simplement allouées dynamiquement par le fournisseur de cloud au moment de l'exécution du code. Et vous ne payez qu'à l'usage réel (pay-as-you-go). Ce qui vous évite de réfléchir aux règles liées à l'élasticité (auto-scaling) de votre infrastructure, tout étant géré par le Cloud. Et ce n'est plus la fonction mais la donnée qui devient la brique première de votre SI.

On peut aussi coupler son code serverless à des micro-services hébergés dans des conteneurs, gérés par Kubernetes (le gestionnaire de conteneur le plus populaire loin devant Mesos ou Docker Swarm) en mode CaaS (Container as a Service).

Et comme le SI est encore en grande partie on-premise, il faut pouvoir gérer le mélange des genres, à savoir un SI hybride, hébergé dans le Cloud Public et dans des centres de traitement traditionnels. Car tout ne passera pas dans le Cloud Public quoiqu'on puisse en dire.

Les 3 phases du SI