Dans quelle mesure les outils et la finalité des tests ont-ils changé ces dernières années ? L’évolution des applications vers le web a rendu nécessaire la création d’outils de test spécifiques. C’est pourquoi nous avons, l’an dernier, étendu nos activités à la gestion des performances. Cette problématique est certes connexe à celle du test, mais complètement nouvelle pour nous. Avec la complexité des systèmes actuels, vous pouvez effectuer tous les tests que vous voulez : ils ne représenteront jamais complètement la réalité du système déployé. Avec les serveurs d’applications, quand on parle d’architectures à trois ou quatre niveaux, on devrait plutôt dire dix. Et, sur chacun, il ne s’agit pas d’un seul élément mais d’instances multiples. C’est la raison pour laquelle je pense que notre approche est la plus pragmatique : il faut connaître le système globalement, du point de vue de l’utilisateur ou du client. Le problème, c’est l’approche ” silo ” : les spécialistes des bases de données, des réseaux, des serveurs ou de la sécurité se renvoient tous la balle en cas de problème.Est-ce si différent de ce qui se pratiquait avant ? En général, on installait un agent sur chaque élément du système, et l’on récupérait les informations pour les agréger sur une console. Cela fonctionne bien pour les systèmes simples ?” par exemple, un mainframe ou un système client-serveur ?”, mais pas pour ceux qui sont plus complexes. C’est pourquoi il est très important de mettre en place toutes les démarches qualité. Mais, par-dessus tout, il faut pouvoir tester l’application dans son ensemble, au niveau des processus métier. Le test de l’interaction des composants n’est pas suffisant. Il y a vingt ou trente ans, lorsqu’il s’est agi d’automatiser les processus dans l’industrie manufacturière, on n’a pas cherché à optimiser chaque étape, mais plutôt les processus eux-mêmes, au sens large. En fait, plutôt que de vérifier individuellement chaque composant, il semble plus efficace d’avoir une approche ” de forage “, comme dans les logiciels d’aide à la décision, pour identifier les problèmes le plus rapidement possible. Concrètement, il existe deux façons d’optimiser une application. La première consiste à la régler : nous pouvons démontrer que 70 % des difficultés peuvent être résolues par des réglages. La seconde consiste à optimiser l’application sur la base des coûts et à essayer d’économiser sur l’infrastructure. Quitte à réemployer cette dernière sur d’autres applications. Nous venons de commencer cette activité d’optimisation. Et nous comptons énormément dessus, car elle peut générer d’importantes économies pour les utilisateurs. Ceux-ci n’ont, en effet, pas véritablement de moyens d’évaluer la bande passante nécessaire ou la taille des serveurs. Et, bien sûr, constructeurs et éditeurs essaient de leur vendre les plus grosses configurations possible…Les entreprises testent-elles leurs systèmes plus qu’auparavant ? Oui. Et cela parce que les débuts du commerce électronique ont représenté pour elles une rude leçon. Il y a une différence entre une application importante et une application critique. Si cette dernière flanche, vous ne pouvez tout simplement pas travailler. Et une proportion importante des applications web, ou plutôt basées sur IP, sont critiques. D’une manière générale, toutes les applications ouvertes sur les clients le sont.Vous présentez maintenant une offre de services hébergés. Comment se positionne-t-elle ? Nous l’avons lancée il y a deux ans, et elle représente déjà 10 % du chiffre d’affaires de la société. Beaucoup doutent de l’efficacité de ce modèle. Mais c’est une démarche très prometteuse si elle est pratiquée correctement. A l’origine, l’approche hébergée a consisté à prendre les applications classiques et à essayer de les proposer à la demande. En réalité, il faut concevoir de nouvelles applications, complètement adaptées à ce modèle. C’est exactement ce que nous faisons. Les problèmes étant assez génériques, nous pouvons facilement mutualiser certaines ressources. Nous avons déployé une très grande infrastructure : neuf fermes de serveurs ?” cinq aux Etats-Unis, deux en Europe et deux en Asie ?” pour créer la charge à l’extérieur de l’entreprise et cinq cents points de présence, depuis lesquels on peut superviser les applications. Conceptuellement, c’est un service web. Même si les protocoles associés en général aux services web ne sont pas utilisés.Les services web vont-ils modifier la donne à leur tour, aussi bien en termes de tests que de gestion des performances ? Je suis un grand supporter des services web. Et j’aimerais voir le concept s’imposer le plus rapidement possible parce que la complexité et le risque sont une manne pour nous. Songez en effet au niveau de risque : toutes les applications se lient à la volée. Il est désormais impossible de dire ” voici l’application que je dois tester “. Dans le cas extrême, on ne sait même pas à quoi l’on se connecte, quelle infrastructure est utilisée, etc. Vous lancez une requête, vous recevez une réponse, point. Pour les services web, la première chose à faire est de mettre en place des contrats de service. Disposez-vous déjà des outils adaptés, ou devrons-nous attendre un ” Web Service Runner ” ? Nous avons déjà une solution, que l’on peut qualifier d’initiale, mais qui répond aujourd’hui aux besoins du marché. Il est encore très tôt pour les services web, mais ils vont finir par décoller. Même si ce n’est pas de la façon que tout le monde attend. La première vague d’implémentation s’effectuera au sein de l’entreprise pour toutes les fonctions génériques. Mais la vision de services web interentreprises mettra encore du temps à s’imposer. Et cela parce qu’il faut d’abord élever le niveau de confiance des sociétés.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
