Un système d’information est constitué d’un ensemble d’outils destinés à gérer, stocker et traiter des flux d’information. Cette démarche qui consiste à faciliter la diffusion de l’information au sein d’une organisation ne repose pas uniquement sur un système informatique. En effet, un Post-it laissé par une secrétaire sur le bureau de son patron pour lui transmettre un message est considéré comme un système d’information. L’informatique n’est par conséquent qu’un outil parmi tant d’autres mis à disposition des organisations afin de compléter et/ou d’améliorer le système d’information déjà en place.

Toutefois, au départ, utilisé comme un simple outil, l’informatique tend au fur et à mesure des années à devenir le principal outil incontournable d’un système d’information. Les applications et programmes informatiques évoluent désormais dans chaque domaine d’activité d’une entreprise et se répandent dans chaque service d’une entreprise : comptabilité, administration, chaine de montage, etc… Progressivement, les applications mises en place se regroupent au sein d’applications de plus en plus importantes. L’objectif étant à terme d’obtenir une seule et même application qui gère l’ensemble du système d’informations dans l’ensemble des secteurs d’activité de l’entreprise et/ou de l’organisation.

Avec l’évolution des technologies, les applications ont progressivement évolué, les attentes des utilisateurs et des clients également. Autrefois, les entreprises privilégiaient le fonctionnel à l’esthétique, la popularité d’un outil comme l’AS/400 en est un très bel exemple. Cet outil à la fois simple et extrêmement complet d’un point de vue fonctionnel ne doit pas sa renommée à son interface graphique (texte blanc sur fond noir avec des menus uniquement textuels). Il serait aujourd’hui impensable de mettre en place un outil semblable à l’AS/400 au cœur d’un système d’information. De plus, les applications de type client lourd composées d’un exécutable à lancer ont progressivement laissé la place à des applications dites « client léger » accessibles à partir d’un réseau par l’intermédiaire d’un navigateur Web. Cette évolution est due en partie aux évolutions technologiques mais pas seulement car la simplicité de mise à jour de l’application est un facteur non négligeable. En effet, il est beaucoup plus simple de mettre à jour un serveur unique avec une interface Web que de compiler un programme et de le déployer sur l’ensemble des postes du réseau. Chaque utilisateur peut accéder à l’application à partir de n’importe quel PC connecté au réseau doté d’un navigateur Web alors qu’il aurait été nécessaire autrefois d’avoir un poste de travail configuré avec l’application préalablement installée.

L’évolution des systèmes d’informations impliquent en parallèle une évolution des méthodes de travail. La mise en production d’une application n’implique plus les mêmes ressources qu’auparavant, une application passe par plusieurs étapes de validation avant d’être mise à disposition des utilisateurs finaux. Avant, il suffisait de réaliser des modifications et d’ajouter des fonctionnalités à une application pour ensuite l’envoyer à quelques personnes qui pouvaient tester l’application. Une fois ces tests réalisés, l’application pouvait être déployée sur l’ensemble des postes. L’infrastructure des nouvelles applications de type « Client léger » ne permet pas de tels tests, la moindre modification implique un changement commun à tous les utilisateurs de l’application, il faut donc mettre en place un environnement de test similaire à celui de production afin de pouvoir tester les évolutions avant de les envoyer sur l’environnement de production. Cela implique par conséquent d’avoir une double infrastructure matérielle. De plus, il faut prévoir aux départs des moyens de transférer des données de l’environnement de production à celui de test afin de pouvoir reproduire des conditions réelles.

Cette article donne quelques conseils sur le déploiement d’application de type « Client léger ». Principalement basé sur la technologie Java et J2EE, ces conseils peuvent bien évidemment s’appliquer à d’autres technologies. Ces conseils sont tirés de mon mémoire de 4ième année.  J’ai supprimé volontairement des parties confidentiels, je m’excuse donc si cette article peut manquer de cohérance par endroit.

Serveur de Recette

Objectif

La mise en recette d’une application permet au maitre d’ouvrage de pouvoir contrôler et de valider les corrections d’anomalies. L’objectif est d’éviter une éventuelle régression sur la production, ce qui pourrait être gênant pour le client. Le serveur de recette permet également d’avoir des personnes autres que le développeur sur l’application. Les utilisateurs habituels de l’application en production peuvent venir tester les nouvelles fonctionnalités, ce qui apporte un point de vue différent sur l’application. En effet, le développeur souvent occupé à corriger une anomalie sait comment fonctionne l’application et n’effectuera pas toujours les tests de la même manière qu’un utilisateur. Le serveur de recette permet donc d’assurer les différents tests nécessaires afin, qu’une fois mis en place sur la production, l’application fonctionne correctement et réponde aux besoins réels des utilisateurs.

Avantages et Inconvénients

La mise en recette permet de réaliser différents tests et d’obtenir une eventuelle validation par le maître d’ouvrage pour une éventuellement mise en production, ce qui à priori ne présente que des avantages.

Pourtant, j’ai constaté que quelques inconvénients pouvaient être évités :

• Les différences possibles entre les environnements de recette et ceux de production même avec des languages comme Java qui pourtant est un langage dit portable, c’est-à-dire qu’en principe, il suffit de compiler une application une seule fois pour l’exécuter sur n’importe quel système d’exploitation. Malgré cela, une application peut présenter des différences de comportement entre l’application mise en recette et celle mise en production. Cela est dû au fait que le système d’exploitation Windows et Linux n’utilise pas le même système de permissions d’accès aux fichiers. Il est donc conseillé d’utilisé le même système d’exploitation afin d’éviter de réaliser certain tests directement sur le serveur de production ce qui peut avoir pour conséquence l’indisponibilité de l’application
• J’ai eu l’occasion de me rendre chez un client afin de débugger une application en cours de développement. Cette application ne disposait par de serveur de recette mais les développements était réalisés à distance sur un serveur. Cette solution permettait au chef de projet de constater l’évolution du développement de l’application quotidiennement. Cette solution aurait pu être viable si elle avait pris en compte les contraintes techniques et matérielles de notre client. En effet, le développement de l’application se faisait en France alors que le serveur de développement se trouvait être à Londres. La connexion internet entre les deux se trouvait être particulièrement mauvaise voire inexistante par moment. L’utilisation de Visual Studio comme environnement de développement permet de développer un programme sur un serveur distant mais, du fait d’une connexion lente, chaque compilation du programme pouvait prendre près de 10 à 15 minutes. Lorsque l’on exécute les dernières modifications, il n’est pas rare de devoir compiler plusieurs fois un programme afin de vérifier si l’on a rien oublié. Dans notre cas, nous avons dû parfois attendre plus de 10 minutes pour nous rendre compte que nous avions juste oublié une accolade ou une parenthèse. Comme notre client était une grosse structure, il nous a été impossible d’obtenir l’autorisation de réaliser cette application en local. Cette solution nous a donc fait perdre non seulement du temps, mais elle a fait perdre de l’argent à notre client.

Serveur de Production

Contexte

Cette exemple traite d’un cas de mise en production dans un environnement J2EE. La mise en production est toujours une opération délicate, elle ne doit pas ou peu influencer les clients de l’application. Le modèle MVC natif de Tomcat facilite des mises à jour rapides. En effet, dans le cas d’une modification des vues, il suffit simplement de faire de la manipulation de fichiers en remplaçant les pages JSP par les nouvelles corrigées et en vidant le cache de Tomcat. Cette opération se fait de manière totalement transparente pour l’utilisateur. En revanche, dans le cas d’une modification sur le contrôle ou le modèle, le remplacement des fichiers n’est pas suffisant, il est alors nécessaire d’effectuer un redémarrage de Tomcat afin qu’il prenne en compte les nouvelles classes et les modifications.

Dans le cadre d’une mise à jour complète, l’accès à l’application doit être bloqué afin de pouvoir supprimer et de réinstaller l’application. Il faut alors bien faire attention à effectuer une sauvegarde des fichiers de configuration et éventuellement d’autres fichiers nécessaire au fonctionnement de l’application. En effet, la réinstallation d’un package WAR sur Tomcat remplace tous les fichiers sans distinction. Cette mise à jour complète doit avoir lieu au moment où l’application est peu utilisée.

Parfois, il est nécessaire d’effectuer des opérations sur la base de données. Il faut alors faire très attention aux requêtes utilisées car la moindre erreur peut engendrer une destruction des données ou une incohérence dans la base. C’est pourquoi, avant chaque modification sur la base de données, il est nécessaire de réaliser une sauvegarde. Une sauvegarde peut prendre du temps et réduire les performances de MySQL. Il est donc souhaitable de couper temporairement l’accès à l’application.

La mise en production d’un système d’information est une opération à laquelle il faut faire très attention. La moindre erreur peut rendre l’application indisponible pendant plusieurs heures, ce qui peut être dommageable pour le client. La destruction des données n’est pas acceptable pour une application qui propose un service payant. Il faut donc prévoir avant chaque intervention une sauvegarde qui permet en cas de problèmes d’assurer un retour en arrière.

Bilan de l’étude

Le passage progressif des applications clientes lourdes aux applications client-serveur permet de centraliser d’avantage l’ensemble des informations. La simplicité d’utilisation des navigateurs Web rend particulièrement appréciable cette nouvelle utilisation pour les utilisateurs. D’ailleurs, la mobilité de ces derniers croît de plus en plus. Un utilisateur n’est plus toujours amené à utiliser le même ordinateur tous les jours. Auparavant, les clients lourds contraignaient les entreprises à installer l’ensemble des applications sur tous les postes. Mais aujourd’hui, les clients légers permettent un accès de n’importe où sur le réseau.

Les méthodes de travail ont progressivement suivi cette mutation des architectures. Les processus de validation et de déploiement d’une évolution se sont profondément simplifiés. Auparavant, les procédures de tests étaient complexes et relativement longues car il fallait déployer l’application à l’ensemble des testeurs. Aujourd’hui, une fois la mise en recette effectuée, ce sont les différents testeurs concernés qui viennent tester l’application ce qui permet de gagner du temps. La mise en production d’une évolution sur un système d’information déjà en fonctionnement est une période délicate qui ne doit pas laisser la place au hasard. Même s’il est parfois nécessaire de stopper l’application, la plupart des mises à jour se fait de manière transparente pour les utilisateurs. Ce confort d’utilisation est particulièrement apprécié car les clients de l’application n’ont pas à se soucier de savoir s’il dispose de la dernière version de l’application. L’architecture client-serveur garantit à chaque connexion d’avoir toujours la dernière version corrigée.

Technique

Les différentes phases d’une mise en production sont nombreuses et varient en fonction de chaque application. Dans le cas de l’application de Veille Réglementaire, l’environnement J2EE de Tomcat permet de faciliter la mise en place de ces différentes phases. Même si les différences d’architecture entre le serveur de production et celui de recette ont causé quelques problèmes, la portabilité de l’application est assurée par Java. Cela permet de tester facilement l’application au cours des différentes phases : développement, recette, production.

L’architecture du Modèle-Vue-Contrôleur(MVC) permet de mettre à jour uniquement les fichiers concernés par les anomalies et réduit considérablement la probabilité d’un effet de bord. A la différence d’un exécutable de type « client lourd », la mise en place d’un système d’information sous la forme d’un « client léger » facilite les mises à jour. Cela implique également un changement des méthodes de développement et des processus de validation d’une application. Mais le rendement des mises à jour peut ainsi gagner en efficacité.

Client

La satisfaction du client est le principal objectif lorsque l’on réalise la mise en production d’un système d’information. Il faut donc faire attention à ses exigences et ses propres objectifs. Ainsi, dans le cas d’une application dont le principal objectif est de facturer un service aux clients, une indisponibilité prolongée de l’application n’est pas envisageable. De même, l’intégrité des données clientes doit être conservée. La volonté d’assurer des mises en production rapides sans réels dommages pour le client est de plus en plus fréquent mais elle nécessite de faire de plus en plus attention. La mise en production est une partie importante de la relation avec le client. En effet, elle implique une relation de confiance entre les responsables du développement et les utilisateurs. Cela contribue à la réussite du projet.