Savez-vous ce qu’est un monolithe ?
Attendez… je parle du monde de l’IT et non de 2001, l’Odyssée de l’espace! (by the way, si vous ne l’avez pas vu… vous devriez!). Pour comprendre pourquoi on parle depuis quelques années maintenant des applications « monolithes » (et par opposition à quoi…), il faut regarder un peu les évolutions des Systèmes d’Information .
La question m’ayant été posé récemment, je me permets un modeste témoignage de ce que j’ai pu observer dans l’IT sur les dernières décennies: celle d’aller globalement vers plus de modularité.
C’est une bonne idée, la modularité, me direz-vous sans doute. Mais ce qui est intéressant c’est de voir à quel point cela soutient les initiatives et les enjeux du Business.
Etape 1 : La création du monolithe
Historiquement, avant l’an 2000, des nombreuses organisations ont mis en place des applications. Ces dernières visaient à traiter leurs flux croissants d’information, et au passage mettre sous contrôle leurs processus administratifs, industriels et commerciaux. Souvent, une des motivations était le fameux « Bug de l’an 2000 » qui promettait de nous ramener à l’âge de pierre dès le 1er Janvier. Mais c’est une autre histoire!
Dans ce contexte, chaque métier, chaque BU, chaque population d’utilisateur connaissait son propre métier. Chacun pouvait définir ses processus et mettre en place un applicatif répondant à ses attentes et besoins. Très vite le partage de données devenait une question cruciale. Comment l’équipe Commerciale peut-elle partager ses prévisions de commandes avec l’équipe de Production ?
La première réponse a été de mettre en place des ERP (Enterprise Ressource Planning en Anglais – PGI ou Progiciel de Gestion Intégrée en Français). C’est-à-dire une seule et même application pour tout le monde (ou presque). Du coup, c’est simple, une seule énorme base de données et tout le monde partage la même information. Tout le monde travaille ensemble dans le monde merveilleux des Bisounours…
Cela a amené tout un tas d’autres questions sur la qualité des données et des chantiers entiers de Data gouvernance, mais laissons ça pour une autre fois !
Le fait est qu’à la fin du siècle dernier (déjà…) l’habitude était de mettre en place un monolithe pour répondre à chacun des besoins. Ces monolithes pouvaient avoir un périmètre plus ou moins étendu (toute l’entreprise ou seulement un groupe d’utilisateurs).
Toujours est-il qu’ils étaient un monolithe, dans le sens où ils traitaient complètement plusieurs étapes d’un ou plusieurs processus, pour des utilisateurs donnés et géraient leur propre ensemble de données.
Un exemple pour bien comprendre
Je me souviens des projets SAP ou des applicatifs Achat que j’ai mis en place à cette époque… A titre d’exemple, dans une solution d’e-procurement, on avait toutes les fonctions requises :
- Création, modification, suppression d’un fournisseur
- Création, modification, suppression d’un catalogue achat (liste d’article avec les conditions d’achat)
- Workflow pour l’ensemble du processus
- Création, modification, suppression d’une demande d’achat
- Création, modification, suppression d’une commande d’achat
- Etc…
Chaque applicatif monolithique était développé et géré par une équipe dédiée et pour des utilisateurs dédiés. C’est ça le monolithe ; et il répond à sa propre problématique métier (la gestion des stocks, le traitement d’un type de dossier, etc…).
Si je dois modifier le processus achat par exemple, je vais alors modifier le code (ou le paramétrage) de cette application et je vais m’assurer qu’il n’y a pas de régression (de bug suite à ce changement).
Et les utilisateurs dans tout ça ?
Ce courant marque pour moi, le début de la « transformation digitale » des entreprises.
En mettant en place des Systèmes d’Information et des applicatifs, le métier structure ses processus et les outille. On commence ainsi « engranger de la data ». A partir de là, les utilisateurs demandent des outils pour exploiter la donnée (Business Intelligence, Intelligence Opérationnelle, Analytics…).
La mise en place des applications de type monolithe, a selon moi permis d’adresser ainsi de façon efficace les besoins de transformation des métiers avec l’arrivée des outils et des « nouvelles technologies ». Cela a permis de mettre en place des réponses sur mesure pour des populations d’utilisateurs.
Alors, un monolithe c’est bien non? Bah oui… mais on a voulu aller plus loin… et c’est ce que nous abordons ici.
Découvrez aussi l’interview de Jérémy Amourous, DSI de Colissimo, qui explique les valeurs ajoutées de la mise en place d’une Architecture Réactive en temps réel.
Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Andrea
