3 projets ont été choisi afin de couvrir le maximum de compétences demandées.
◽ C'est la solution propriétaire du groupe MH pour la gestion des contrats.
◽ 1500 utilisateurs simultané qui interagissent avec l'application pour la gestion des contrats.
◽ 35 serveurs de production virtualisés.
◽ Plus de 5 millions de lignes de code maintenues et évolutives.
Pléiade est maintenu et évolue via une série de projets structurés qui suivent un cycle en V:
◽ Définition du périmètre: Identification des besoins et des fonctionnalités à développer ou à améliorer.
◽ Conception: Modélisation et architecture des solutions techniques.
◽ Spécifications: Rédaction des spécifications fonctionnelles et techniques.
◽ Développement: Phase de codage des nouvelles fonctionnalités et corrections.
◽ Tests de Validation Interne (TVI): Tests initiaux réalisés en interne pour vérifier la conformité aux spécifications.
◽ Recette (Tests de Recette Fonctionnelle - TRF): Phase de tests utilisateurs, où la version est validée en conditions réelles avant le déploiement.
◽ Tests de préproduction: Dernière phase de validation avant la mise en production.
L'automatisation des tests de non-régression garantit la stabilité des fonctionnalités existantes en détectant rapidement les éventuelles régressions provoquées par de nouvelles modifications.
◽ X_page: Regroupe les déclarations nécessaires à l'exécution des tests, notamment les composants et éléments ciblés.
◽ X_test: Contient les étapes et instructions détaillées des scénarios de test à exécuter.
◽ Les tests peuvent également être reférencier sur Azure DevOps, ce qui leurs permettent d'utiliser des Paramètres dynamiques.
◽ Analyse des résultats: Les résultats des tests sont centralisés et référencés dans Azure DevOps, où ils peuvent être exécutés, suivis et analysés.
❌ Problématique: La MOA dépend de la MOE pour exécuter et concevoir des requêtes SQL afin d'obtenir des informations essentielles pour mener à bien ses missions.
✔ Une solution: Le SQLTheque permettra de rompre cette dépendance en offrant une bibliothèque de scripts exécutables sur plusieurs environnements, avec des paramètres modulables.
◽ Le SQLTheque sera une application réservée à MH TECH, et, par conséquent, n'aura pas les mêmes privilèges que le DataWiper. La gestion de projet, dans ce contexte, ne sera donc pas nécessaire.
◽ Une maquette a été élaborée pour organiser le contenu de manière structurée.
❌ La mise en place d'une base de données MS SQL Server sera impossible en raison de la nature spécifique du projet.
✔ Pour pallier cette contrainte, SQLite a été sélectionnée, ce qui simplifie également le processus de déploiement.
❔ Origine du besoin : Depuis l'entrée en vigueur du RGPD, MH, étant un acteur clé du secteur de la santé, évolue dans un environnement fortement réglementé.
❌ Problématique : La gestion des données de purge et leur ordonnancement se faisait manuellement, ce qui était peu efficace et présentait des risques de non-conformité ou de perte de données sensibles. Aucun système automatisé n'était en place pour gérer ces processus.
◽ Rôles: Le chef d'équipe a assumé le rôle de MOA, tandis que j'ai rejoint Rémi en tant que contributeur au projet.
◽ Méthodologie: Organisation en mode agile, avec des points réguliers pour suivre l'avancement des fonctionnalités et ajuster les priorités si nécessaire.
◽ Architecture: Mise en place d'une architecture client-serveur de type trois tiers, garantissant modularité et évolutivité.
◽ Technologies : Utilisation de technologies maîtrisées par l'équipe, notamment ASP.Net, SQL Server et JavaScript, pour assurer une mise en œuvre efficace et rapide.
◽ Solution de purge automatisée: Développer une application permettant de gérer les processus de purge des données de manière automatisée, tout en respectant les critères de confidentialité et de sécurité.
◽ Interface utilisateur claire et efficace: Une application robuste permettant à l'utilisateur de configurer, exécuter et suivre les processus de purge des données, tout en étant conforme aux exigences de sécurité et de traçabilité.
Le DataWiper est conçu pour être générique, c'est-à -dire qu'il peut purger les données de n'importe quelle base de données appartenant à MH, quelle que soit l'application concernée :
◽ Parcours de la hiérarchie des tables: Identifie et respecte les relations de dépendance entre les tables.
◽ Filtrage des données à supprimer: Applique des critères spécifiques pour cibler uniquement les données pertinentes. (Filtre)
◽ Flexibilité et adaptabilité: S'adapte aux différentes configurations des bases de données MH.