A l'écoute (2/2)

A l'écoute (2/2)

Pour résoudre les problèmes auxquels les utilisateurs de Lilie se trouvent confrontés, l’équipe support de CGI est aux avant-postes. Lorsqu’elle ne réussit pas à résoudre le problème qui lui est soumis, elle se tourne vers la cellule de coordination qui, après analyse, oriente la demande vers l’équipe de production ou vers l’équipe de développement. Ce sont eux qui sortent la boîte à outils…

Boite à outils

Les causes de dysfonctionnement d’une application informatique complexe sont nombreuses et variées. C’est pourquoi, le dispositif de support des usagers de Lilie fonctionne en cascade. Au premier niveau, la demande est enregistrée et l’équipe support s’efforce de la traiter.  Elle y parvient dans une majorité de cas. Sinon, l’escalade commence. Elle passe d'abord par les équipes techniques.

Panne ou anomalie ?

Au sein de CGI, les équipes techniques se répartissent entre la production (le hard) et le développement (le soft).  Les premières traitent les pannes qui se présentent comme des incidents matériels sur le réseau ou les serveurs. Lorsque, par exemple, l’une des machines qui hébergent l’ENT tombe en panne, une autre prend aussitôt le relais, le temps de réparer ou de changer la première. Mais il arrive que de tels incidents provoquent des perturbations, des interruptions de service, une panne. Les diagnostiquer et réparer ce qui doit l’être, c’est l’équipe de production qui s’en charge.

Si le problème ne provient pas de l’exploitation, la demande est orientée vers l’équipe chargée du développement, du soft donc. Ici, on ne parle pas de panne mais d’anomalie. La demande entre alors dans un nouveau circuit et les choses alors se compliquent un peu…

Mais heureusement pour nous, Glenn Fernandez, responsable de la cellule de coordination centrale ENT, et Romain Lauri, responsable client, sont disposés à nous les expliquer.

Les utilisateurs de Lilie se demandent souvent pourquoi il faut tant de temps pour corriger des bugs, des anomalies qui les gênent et leur apparaissent souvent comme des défauts faciles à corriger. Comment cela se fait-il ?

Glenn FernandezLe flux d’anomalies que nous recevons n’est pas continu. Il nous arrive de devoir prioriser. Les demandes qui gênent peu ou pas du tout le fonctionnement de Lilie sont considérées comme non prioritaires et placées en fin de liste. Du coup, le délai de traitement peut être long. Mais tant qu’elle n’est pas traitée, la demande reste ouverte dans JIRA et sera traitée dans une version à venir. Aujourd’hui, nous arrivons à traiter davantage de demandes que nous en recevons, nous commençons donc à résorber le stock d’anomalies plus anciennes.

Pour traiter les anomalies, nous appliquons une procédure très stricte. Prenons le cas le plus simple. Nous recevons par exemple un signalement de bug qui perturbe le fonctionnement d’un service. Nous décidons de le traiter comme une priorité et de réparer aussitôt. Imaginons que la correction soit faite rapidement, dans la journée par exemple. Même dans ce cas, elle n’est pas aussitôt mise en production. Car nous devons d'abord vérifier que la correction a été bien faite.

Ecran développeur

Les techniciens des équipes de développement travaillent sur des écrans comme celui-ci. Ils doivent suivre une procédure très stricte pour intégrer les modifications, les corrections d'anomalies jusqu'à la plateforme de production.

Cette vérification est réalisée sur une plate-forme d’intégration, une copie de la plate-forme de production. Après que tous les contrôles ont été effectués, et en particulier les contrôles de non-régression, la nouvelle version est encore testée sur une plate-forme de pré-production puis, avec l’accord de notre client, la Région Île-de-France pour Lilie, elle est installée sur la plate-forme de production, celle à laquelle les utilisateurs se connectent. La mise à jour se fait en général pendant la nuit. Tout cela peut prendre plusieurs jours, 3 à 4, c’est un minimum.

Qu’appelez-vous contrôle de non-régression ?

Romain LauriLorsqu’on corrige une anomalie, il peut arriver qu’on en provoque une autre, ailleurs. En principe donc, chaque fois que nous faisons une correction sur une fonctionnalité, nous devons nous assurer que toutes les autres fonctionnalités et tous les services qui en dépendent fonctionnent toujours bien. C’est fastidieux mais indispensable et cela prend forcément du temps.

Une correction peut aussi entraîner une perte de performance. L’anomalie a disparue mais le service est plus lent. Il faut reprendre la correction. Nous devons aussi nous assurer qu’après la correction l’ENT fonctionne toujours bien avec tous les navigateurs. Et vérifier également que la correction est prise en compte avec toutes les configurations de droits et de permissions.

Il faut être très méthodique. Nous avons maintenant une bonne expérience, nous avons réussi à bien stabiliser l’OpenENT et nous sommes à présent capables de le maintenir de mieux en mieux.

Glenn FernandezDans certains cas, nous pouvons faire les corrections directement sur la plate-forme de production. Par exemple, lorsqu’un utilisateur est bloqué à cause d’un paramètre, nous pouvons intervenir directement sur le champ à modifier.

Romain LauriIl faut aussi ajouter que les corrections ne sont pas mises en production une par une. Elles sont regroupées dans ce que nous appelons un « patch correctif », c’est-à-dire un lot de corrections que nous intégrons régulièrement dans une nouvelle version de la solution. En ce moment, nous travaillons sur une nouvelle version, la 2.1.9 qui sera mise en production cet été dans le cadre de la bascule d’année.

Vous pouvez nous assurer que tout se passera bien cette fois ?

Nous avons pris toutes les dispositions pour cela ! La version de septembre, la 2.1.9, est prête sur la plate-forme de pré-production. Il y a trois semaines, nous avons commencé les répétitions de mise en production et de bascule d’année. Nous prévoyons de répéter encore trois semaines et nous aurons tout mis en œuvre pour que le passage à la nouvelle année soit réussi.

Merci messieurs !