PaaS : quand la production d’applications devient un non-évènement

Le PaaS remet en cause les citadelles de la DSI : études, développement, exploitation, production... Il refond profondément sa relation avec les directions métiers.

Le PaaS, pour Platform as a Service, est “un type de cloud computing qui permet de mettre à disposition des entreprises un environnement d'exécution rapidement disponible, en leur laissant la maîtrise des applications qu'elles peuvent installer, configurer et utiliser elles-mêmes”. Voici une bien belle définition dont Wikipédia a le secret, mais ça ne dit pas quel est le prodigieux rôle du PaaS.

Il faut en effet voir le PaaS comme une véritable rupture technologique dans la manière de produire des logiciels. Et son impact est tellement sidérant qu’il est impératif pour les entreprises de se préparer, car il remet en cause la chaîne “classique” de création des logiciels.

La démarche “legacy” de production d’applications peut se résumer ainsi : d’abord la conception avec les métiers, le développement, puis la livraison, la mise en production, et l’exploitation au quotidien. On parle donc bien d’un produit livré aux équipes d’exploitation qui auront la charge de sa mise en production et son exploitation au quotidien. Equipes au pluriel : il y a une équipe qui s’occupe de la réception du logiciel, une autre qui s’occupe de le packager, une autre qui va s’occuper de l’infrastructure réseau, une autre de l’infrastructure système, une autre du hardware, une autre de la sécurité, une autre du suivi opérationnel... Autant d’équipes qui fonctionnent en mode silo, avec des processus compliqués qui limitent les responsabilités de chacun et qui définissent les transitions entre les silos.

Avec le PaaS, qui amène l’automatisation et l’hyper-industrialisation, tous ces silos sont amenés à disparaître ! Ni plus ni moins. Toutes les équipes de production peuvent être remplacées par une seule plateforme, toutes les activités de la production deviennent consommables par API, exactement comme le IaaS qui définit que toutes les infrastructures machines, réseaux et stockage sont consommables par API. Pour s’amuser avec les acronymes, on ne parlerait plus alors de Plateforme as a Service, qui est un concept, mais de Production as a Service, bien plus concret.

De ce fait, tous les environnements structurés de développement, de pré-production, de beta-testing... n’ont plus lieu d’être. Il en va de même de l’approche d’environnement par applications ou par métiers. Car avec le PaaS, les environnements se créent et se suppriment à la demande, très rapidement, au gré des besoins. Qu’il faille 5 environnements de tests de qualification ou 50, les coûts variables avec le PaaS sont quasi nuls.

Ainsi, le développeur va pouvoir se consacrer à une activité et une seule : la conception et le développement logiciel. C’est-à-dire qu’il va écrire du code pour les métiers. Et dès lors qu’il aura terminé l’écriture de son code, tout le processus est automatisé. En effet, l’API PaaS va venir chercher le code, le compiler en fonction de sa nature (quelle que soit la technologie utilisée, PHP, Java, Scala…), puis le “builder” avant de le livrer dans son environnement (développement, pré-production, production…).

Le PaaS va également mettre à jour tous les systèmes de sécurité et de monitoring (reverse-proxy, répartiteurs de charge, éléments réseaux…) pour que l’application puisse s’exécuter conformément aux principes de sécurité préétablis. Ce n’est pas tout, puisqu’une fois l’application déployée, c’est le PaaS qui se charge de sa surveillance au quotidien, 24h sur 24, 365 jours par an. Si l’application tombe, c’est le PaaS qui va la remettre en route, tout en émettant des alertes pour trouver pourquoi il y a eu un “plantage” et procéder ultérieurement aux actions correctives appropriées. C’est également le PaaS qui surveille son comportement en termes de scalabilité en fonction de la sur-sollicitation par exemple. Dans ce cas précis, c’est lui qui va la dupliquer sur d’autres instances, et provisionner les éléments du réseau concernés, pour faire face à cette montée en charge (et inversement, le PaaS peut réduire la voilure si l’application est peu ou pas sollicitée). Le coût de l’infrastructure est donc ajusté à la quantité de requêtes et au nombre d’utilisateurs connectés. 

Synthétiquement, le PaaS permet de mettre en production une application quelle que soit sa technologie, quel que soit le langage de développement utilisé. C’est une plateforme polyglotte hyper-réactive, qui rend la production et l’exploitation extrêmement réactifs, permettant aux métiers de choisir les équipes et les technologies qui sont réellement adaptées à leurs besoins et les contraintes afférentes. Les répercussions sur l’entreprise sont donc très importantes, et des ruptures se forment même au-delà de la DSI. 

La première rupture est culturelle : les contraintes de “socle” (le respect des normes et des standards de production) volent en éclat. Avec le PaaS, il n’y a plus aucune contrainte technologique à (op)poser aux équipes études et développement et par transitivité aux équipes métiers. La production est technologiquement agnostique. La deuxième rupture est organisationnelle : avec le PaaS toutes les activités liées à l’infrastructure, à l’exploitation et la production d’applications sont entièrement automatisées. De fait, les métiers chargés de réceptionner une application, de mettre à jour les fichiers de configuration, de qualifier l’application avant sa mise en production, de la mettre en production, de la surveiller… sont tous amenés à disparaître. 

La troisième rupture est globale : est-ce que l’entreprise, via ses processus métiers, est prête à supporter une énorme accélération dans la création de nouvelles applications ? Car le PaaS, en tant que Production as a Service, est un formidable accélérateur business. Il permet à tout métier de choisir ses propres équipes de développeurs, qui utilisent les technologies qu’ils aiment, de concevoir et développer leurs propres applications et les livrer en production en totale autonomie. 

Le PaaS révolutionne donc toute l’entreprise et pas uniquement la DSI, puisqu’il peut donner de nouvelles ambitions aux responsables métiers, qui vont se rendre compte qu’ils peuvent avoir leurs propres développeurs, leurs propres informaticiens. Et ainsi construire leurs propres applications au service de leur propre business et en dehors de toutes contraintes centrales posées par les départements architectures ou exploitation, mais elles restent quand même livrables sur la plateforme de production de leur entreprise qui dispose des certifications et garanties de sécurité. 

Le PaaS peut donc libérer la DSI des tâches de conception et de développement d’applications, qui peut se retrouver chez les métiers. La DSI doit alors s’attacher à offrir aux métiers l’infrastructure, le IaaS, le PaaS et la cybersécurité afférentes. La DSI se transforme donc d’une Direction des Systèmes d’Informations en une Direction de la Sécurité et de l’Infrastructure. La DSI est morte, vive la DSI !