Je sais m'adapter. J'aime le changement et les défis. Ces derniers temps, toutefois, j'ai l'impression de traverser l'hyperespace à bord du Faucon Millenium d'Han Solo.

En dix ans, les technologies de l'information ont tellement évolué en apportant son flot de bonnes et de mauvaises nouvelles : les écrans verts CICS à gestion centralisée sur mainframe ont pratiquement disparu, mais personne n'aurait eu l'idée de les pirater. Lorsque la gestion était centralisée, les utilisateurs de stations personnalisables n'appelaient pas l'assistance technique pour se plaindre que l'écran de connexion ne s'affichait pas (après avoir augmenté la résolution de l'écran au-delà des limites raisonnables).

Au-delà des changements visibles, nous devons également nous adapter à la technologie sans fil, avec des périphériques portables offrant des fonctions qui nécessitaient jusqu'alors une connexion matérielle et d'autres " nouveautés du jour ".

Prenons le cas des e-mails. Il y a deux ans, les étudiants de l'université George Washington ne pouvaient pas passer à côté d'une borne sans venir vérifier leur messagerie. Aujourd'hui, l'e-mail est dépassé. Supplanté par la messagerie instantanée, les messages texte, les fonctions Facebook et les blogs qui permettent une communication peer-to-peer quasi instantanée. Chaque fois qu'une nouveauté intéressante sort, les étudiants en sont informés avant même que nos informaticiens aient eu connaissance de son existence. Et les universités ne peuvent pas interdire ces appareils, tout ce qu'elles peuvent faire c'est indiquer qu'elles n'offrent pas la structure technologique adaptée.

Gérer les environnements complexes

Les environnements que nous gérons aujourd'hui nous permettent d'offrir aux utilisateurs des services via des moyens jusque là impensables.Toutefois, les nouveaux produits et outils informatiques, toujours plus nombreux, nécessaires à la fourniture de ces services étendus, ont singulièrement compliqué notre environnement.

À George Washington, nous utilisons les suites ERP SunGard Banner Higher Education et le module Finances d'Oracle. Nous déployons également la suite EMC Documentum® à l'échelle du campus. Si l'on ne tient compte que des cycles de gestion de l'université (recrutement, admissions, bourses, inscriptions, hébergement, etc.) ou encore les procédures comptables imposées par les lois fiscales fédérales, la planification des mises à niveau et des tests est déjà bien compliquée. La dernière analyse que nous avons réalisée indique que le cinquième jeudi de mars, les années bissextiles, serait le moment idéal pour ces mises à niveau...

Et cela ne concerne que les systèmes visibles pour les utilisateurs. Les bases de données, serveurs, systèmes d'exploitation, systèmes d'utilitaires, le SAN et les logiciels de sauvegarde ont leur propre cycle d'actualisation. George Washington maintient des environnements de test et de développement pour chaque serveur et application de production, et gère des centres de données redondants se supportant mutuellement. Mais trouver le moment le moins coûteux pour implémenter un composant reste difficile.

D'autre part, même si les technologies de l'information sont censées évoluer vers des architectures orientées services, l'effort à fournir par les utilisateurs pour assimiler les nouvelles fonctions logicielles et les procédures de test et de configuration de ces fonctions supposent une plus grande implication de chacun. (J'attends encore qu'un responsable de département me supplie de cesser de lui faciliter la vie.) Certains leaders du secteur informatique développent quand même des composants plug-and-play qui nous aident à modifier l'infrastructure à la volée, sans intervention risquée ou ingérable de l'utilisateur final.

Insister sur l'importance des tests collaboratifs

Pour implémenter les dernières versions et mises à niveau des systèmes ERP, nous avons mis au point un processus (que nous continuons d'améliorer) qui met l'accent sur les tests réalisés de manière collaborative par les utilisateurs et les informaticiens.

Pendant le premier tiers du projet, notre équipe se consacre à l'analyse du contenu de la version puis identifie les modifications et améliorations apportées. Elle prépare toutes les étapes de la procédure de test : organisation des serveurs et des bases de données, test des clients bureautiques, analyse de la sécurité et préparation des scripts de test pour les utilisateurs. Chaque heure consacrée à ces préparatifs permet de réaliser une analyse plus poussée et évite de ralentir en aval le fonctionnement du campus.

Dans un deuxième temps, les informaticiens expliquent les nouvelles fonctions aux utilisateurs " avancés " des principaux services et leur apprennent à former les utilisateurs finaux. Ces utilisateurs avancés appliquent les scripts de test, leur connaissance des procédures et de la précédente version du logiciel pour analyser et vérifier les bienfaits de la nouvelle fonction.

Nous consignons toutes les anomalies relevées. Certaines sont de vrais problèmes, d'autres de simples difficultés de compréhension, d'autres encore sont liées à une erreur du script de test. En règle générale, les anomalies sont issues de rapports sur les éléments modifiés dans une base de données, des interfaces ou étapes de navigation inconnues, ou encore sur des changements venant contredire des choses acceptées jusque-là. Nos programmateurs travaillent avec l'éditeur ERP sur tous les problèmes rencontrés. Généralement, ces problèmes sont rapidement résolus et la solution de nouveau soumise aux utilisateurs pour confirmation.

Lors de la phase finale, les représentants des utilisateurs donnent leur accord sur la mise à niveau, et un responsable de niveau C donne le feu vert. Nous finalisons alors les détails techniques avant de mettre le logiciel en production. Le plan de mise en service démarre (il est extrêmement détaillé, souvent par demi-heure), et le système est mis en ligne à une heure et une date précises.

Cette procédure est indispensable en raison du grand nombre d'utilisateurs (des milliers) à George Washington, du nombre limité de fenêtres permettant d'apporter des modifications importantes au système, et du temps et de l'énergie considérables que nécessite une telle implémentation. Lorsqu'il s'agit d'une mise à niveau de base de données ou de l'application de correctifs, opérations moins perturbantes, nous utilisons une version allégée du processus pour nous assurer que le système fonctionne comme auparavant, juste plus efficacement ou de façon plus sûre.

L'attention que nous portons aux détails nous a permis de mettre à niveau plusieurs systèmes ERP d'envergure sans avoir à revenir à une version précédente en raison de problèmes imprévus. Chaque plan de mise à niveau comporte toutefois une date butoir de sécurité en cas de mauvaise surprise de dernière minute. Le simple fait de la fixer (en général, dans les quinze jours) permet de travailler sereinement, sans penser aux risques. Les décisionnaires, quant à eux, profitent ainsi d'une échappatoire logique et pratique. Dégagés de toute moins de pression, nous analysons les risques plus rationnellement.

Bill Gates aurait dit que si General Motors avait fait évoluer la technologie comme l'a fait le secteur de l'informatique, nous conduirions tous des voitures à 25 dollars parcourant 1 500 kilomètres avec à peine un demi-litre d'essence. Mais si les avancées de l'industrie automobile suivaient le rythme de celles du secteur informatique, nous devrions faire poser de nouveaux pneus en janvier, changer les airbags en février et installer de nouveaux freins céramiques en mars.

Nos environnements informatiques, eux, ne se simplifieront jamais, mais lorsque nous les modifions, nous pouvons faire en sorte de limiter les conséquences pour les utilisateurs. Ce que nous voulons tous, c'est offrir des services plus efficaces et plus économiques. C'est donc sur les effets négatifs involontaires de modifications globalement positives que nous devons nous concentrer.