Le ministère de la Défense s’est équipé de solutions de tests et de gestion des exigences pour garantir la fiabilité et l’interopérabilité de son système d’information. Témoignage du capitaine Yann Guillou, architecte solutions au ministère de la Défense.
C’est pour gérer la logistique du parc des matériels terrestres (véhicules, armements, optique, transmissions…) que le ministère de la Défense a mis en œuvre, dès 2005, un système centralisé : SIM@T (Système d’Information de la Maintenance Terrestre). En réalité, il s’agissait de remplacer le système d’information de la maintenance de l’armée de Terre, conçu dans les années 1990. Un mouvement de modernisation qui a permis d’intégrer la gestion des approvisionnements en 2011, la planification des approvisionnements et des référentiels en 2012 et, enfin, la gestion des achats et des matériels complets en 2013.
Aujourd’hui distribué sur 250 sites géographiques et utilisé par 5 000 personnes, le système assure la gestion des parcs de matériels, le suivi des interventions techniques, les approvisionnements et les achats. Le capitaine Yann Guillou, architecte solutions, indique que « c’est pour mieux contrôler le processus de développement du SIM@T que la sous-direction des Systèmes d’information de la Structure intégrée du maintien en condition opérationnelle des matériels terrestres (SDSI, SIMMT) a décidé d’investir dans des solutions de test, de modernisation et de collaboration. »
Des modèles de données distincts des tests
C’est tout d’abord en qualité de Test Manager que le capitaine Yann Guillou intègre la SIMMT en 2008. À ce moment-là, le ministère de la Défense possède déjà des outils capables de gérer les différents niveaux du référentiel métier. « Mais la gestion des modèles de données et des tests était distincte. D’où un manque de visibilité entre l’expression du besoin et ce qui devait être testé en fin de cycle. » Pour y remédier, il est chargé de mettre en place des mécanismes de test, jusqu’alors inexistants.
« Il a fallu définir des stratégies, s’assurer que les tests effectués étaient conformes aux besoins d’exigence exprimés. À cette époque, nous utilisions les outils de traçabilité et de test de Compuware et Borland », précise le capitaine Yann Guillou. La stratégie de test validée, c’est en tant qu’expert technique qu’il doit faire évoluer les méthodes de test. « Il était important de réaliser à nouveau des études d’impact. De ce fait, s’il y avait une modification sur un référentiel dont nous avions la maintenance, il fallait être capable de dire que telle donnée modifiée avait un impact sur tel ou tel autre traitement. » Et c’est finalement en tant qu’architecte solution que le capitaine Yann Guillou pourra répondre à ce besoin. C’est-à-dire réduire le cycle de test pour optimiser les processus de développement logiciel tout en mesurant l’impact des changements effectués et veiller au maintien de la qualité des données.
Un test de la solution de test
Le ministère de la Défense va aborder ce projet avec deux objectifs : tester la solution, avant de s’investir financièrement, et impliquer les utilisateurs dans les différentes étapes de sélection. Une première étude permet d’éliminer certains prestataires tels que HP, IBM, ou autres solutions Open Source. En effet, soit les logiciels ne garantissent pas la reprise des données, soit ils présentent des lacunes dans leurs fonctionnalités ou, encore, sont trop onéreux. Le ministère a sélectionné Micro Focus et ses logiciels Caliber, Together, Silk Central, Silk Test et Silk Performer pour tester et implémenter les nouveaux modules réécrits en Java.
Mais, avant de s’engager définitivement, la SDSI va s’assurer de la fiabilité des logiciels. « Tester la solution était impératif. C’est pourquoi, dès 2011, nous avons réalisé une étude et un prototype, et entériné notre choix deux ans plus tard. C’est le temps qu’il a fallu pour que la solution arrive à maturité », assure l’architecte solution. Cette phase lui a permis de vérifier la qualité de la reprise des données, d’examiner la correspondance entre les besoins et les fonctionnalités des solutions, de mesurer la performance de la solution et, enfin, de rectifier les méthodes.
Pour garantir la réussite du changement, la SDSI va mettre en place des pratiques de conduite du changement, bien avant le lancement du projet. « Nous avons organisé des réunions avec les utilisateurs pour les informer et évaluer leurs besoins. Nous voulions les fédérer et les mobiliser autour d’un objectif commun. Ce qui était loin d’être évident, car un utilisateur résiste généralement au changement », avoue le capitaine Yann Guillou.
Des fiches de test pour les utilisateurs
Au cours de ces échanges, les utilisateurs vont détailler, schématiser leurs tâches pour que la SDSI puisse concevoir un système d’information capable de répondre à leurs besoins. Puis les utilisateurs interviennent une seconde fois, lors des phases de tests, de révision et de validation. Comme l’explique le capitaine Yann Guillou, « l’utilisateur devait valider toutes les étapes au moyen d’une fiche de test, afin que nous puissions disposer d’un tracé plus précis. Ainsi, si au travers d’une phase de tests d’un logiciel, nous repérions des dysfonctionnements, nous pouvions les identifier immédiatement et savoir quels étaient les impacts au niveau du système d’information et prévoir les actions à mener. » Et même si le capitaine Yann Guillou a remarqué une certaine réticence des utilisateurs, celle-ci s’est vite dissipée. « Avant tout changement, il faut prendre le temps d’échanger avec les utilisateurs pour comprendre leurs besoins, leur démontrer le bien-fondé d’un outil plus performant. C’est le premier accompagnement. Puis, dans un second temps, il faut trouver les outils qui répondent à leurs manquements. Et, enfin, mettre en place des formations adaptées. Si tous ces paramètres sont pris en compte, le retour d’expérience se passe bien. »
D’ailleurs, il reconnait que le travail collaboratif est désormais facilité grâce au logiciel Caliber. « Quand la phase de conception se termine, nous pouvons en informer toutes les parties prenantes avec Caliber qui standardise ainsi la collaboration entre les différentes équipes. » La SDSI mentionne également une réduction des délais de développement et de tests, une vérification de l’impact du changement jusqu’au niveau d’un champ de données, une meilleure visibilité des réalisations et une maîtrise de la structure des données.
Les bonnes pratiques du ministère de la Défense
- Faire intervenir les utilisateurs dans toutes les phases du projet : réflexion, élaboration, tests et validation.
- Prendre le temps d’écouter et de retranscrire clairement les besoins des utilisateurs.
- Privilégier les tests en termes de performances et de fonctionnalités.
- Ne pas hésitez à malmener le logiciel, à changer le paramétrage, etc., pour mieux coller aux besoins des utilisateurs.
- Prendre en compte les conseils et les méthodes des prestataires.
Tests : les treize idées fausses
- Le développeur est le plus à même de tester son programme.
- Le test et la recette constituent de simples formalités.
- Le test est essentiellement l’affaire de la maîtrise d’œuvre.
- Les outils logiciels règlent tous les problèmes d’homologation applicative.
- Un Plan d’Assurance Qualité (PAQ) garantit la qualité d’une application et la dispense de tests approfondis.
- Les progiciels de gestion intégrés (ERP) n’ont pas besoin de tests.
- La garantie d’un projet réussi, c’est la sous-traitance au forfait.
- Le test coûte cher.
- Les tests préparent la recette, mais ne mesurent pas la qualité.
- La connaissance exclusive de l’environnement technique ou fonctionnel est indispensable à l’activité de test.
- Réorganiser globalement son activité de test et recette est une décision facile à prendre et très difficile à mettre en œuvre.
- Les nouvelles méthodes de développement repensent entièrement les tests.
- L’excellence dans le test et la recette, c’est uniquement la responsabilité d’une équipe spécialisée et des infrastructures techniques dédiées.