ÉCOLE D’INGÉNIEURS EI-CNAM

Mémoire de projet de fin d’études

Pour l’obtention du diplôme d’ingénieur d’état en Xxxxxxxxx

ARCHITECTURE 2-TIERS POUR UN SYSTÈME DE

CONSULTATION DE LOGS EN TEMPS RÉEL

SOUIDI Bilel

Composition du jury :

Président : Pr. NOM Prénom

Promotrice : Dr. NOM Prénom
Examinatrice : Dr. NOM Prénom
Abstract

In today’s fast-paced industrial environment, the ability to quickly access and analyze produc-
tion logs can make the difference between efficient operations and costly downtime. This thesis
explores the development of a real-time log consultation system that transforms how production
teams access critical diagnostic information.

Working within the constraints of an existing industrial infrastructure, I designed and imple-
mented a 2-tier architecture that seamlessly integrates with production and test stations. The
solution combines the reliability of MySQL for data centralization, the flexibility of Python
for automated data processing, and the responsiveness of Node.js for real-time web interfaces.
What makes this approach unique is its focus on practical usability - the system doesn’t just
collect data, it presents it in a way that production teams can actually use to make quick,
informed decisions.

The implementation results demonstrate tangible improvements in information access speed

and decision-making efficiency. While the journey wasn’t without challenges - particularly in
integrating with legacy systems and ensuring real-time performance - the final solution provides
a solid foundation for future enhancements and advanced analytics integration.

Keywords : Real-time logs, 2-tier architecture, MySQL, Python, Node.js, industrial produc-
tion, decision support systems.
Résumé

Dans l’environnement industriel actuel, où chaque minute compte, l’accès rapide aux logs de
production peut faire la différence entre un processus optimisé et des arrêts coûteux. Ce mémoire
retrace le développement d’un système de consultation de logs en temps réel qui révolutionne
la façon dont les équipes de production accèdent aux informations diagnostiques critiques.

Face aux contraintes d’une infrastructure industrielle existante, j’ai conçu et implémenté une
architecture 2-tiers qui s’intègre harmonieusement avec les postes de production et de test. La
solution allie la fiabilité de MySQL pour la centralisation des données, la flexibilité de Python
pour le traitement automatisé, et la réactivité de Node.js pour les interfaces web temps réel.
Ce qui rend cette approche unique, c’est son orientation vers l’utilisabilité pratique - le système
ne se contente pas de collecter des données, il les présente de manière à ce que les équipes de
production puissent réellement les utiliser pour prendre des décisions rapides et éclairées.

Les résultats de l’implémentation démontrent des améliorations concrètes en termes de rapidité

d’accès aux informations et d’efficacité dans la prise de décision. Si le parcours n’a pas été sans
défis - notamment dans l’intégration avec les systèmes existants et l’assurance des performances
temps réel - la solution finale offre une base solide pour les améliorations futures et l’intégration
d’outils d’analyse avancés.

Mots clés : Logs en temps réel, architecture 2-tiers, MySQL, Python, Node.js, production
industrielle, systèmes d’aide à la décision.

Page 2
Remerciements

Ce projet n’aurait jamais vu le jour sans l’aide et le soutien de nombreuses

personnes qui ont cru en moi et en cette idée. Permettez-moi de leur exprimer
ma gratitude la plus sincère.
À l’équipe MPSI, qui m’a accueilli comme l’un des leurs et m’a donné la chance
de comprendre les vrais défis de la production industrielle. Merci pour votre
patience quand je posais des questions "naïves", pour votre expertise technique
qui m’a tant appris, et pour votre confiance qui m’a permis de tester mes idées
sur le terrain.
À mes encadrants académiques, qui ont su me guider sans me dicter, me laissant
l’espace nécessaire pour faire mes propres découvertes et mes propres erreurs.
Vos conseils ont été précieux, surtout dans les moments où je doutais de mes
choix techniques.
À mes collègues stagiaires et aux développeurs qui m’ont aidé à déboguer ce code
parfois têtu. Les longues sessions de programmation, les discussions techniques
passionnées, et même les moments de frustration partagée ont fait de cette
expérience quelque chose de vraiment spécial.
À ma famille, qui a supporté mes nuits blanches, mes humeurs changeantes
selon l’état du projet, et qui m’a toujours rappelé que l’échec fait partie de
l’apprentissage. Votre soutien inconditionnel a été mon ancrage pendant toute
cette aventure.
Et enfin, à tous ceux que j’ai oubliés de mentionner mais qui ont contribué,
même indirectement, à la réussite de ce projet. Chaque interaction, chaque
conseil, chaque encouragement a compté.
Ce mémoire est le fruit de cette collaboration humaine, et j’en suis profondément
reconnaissant.

Souidi Bilel.
Table des matières

Liste des tableaux 11

Table des figures 12

Liste des acronymes 16

Introduction générale 18

1 CONTEXTE ET PROBLÉMATIQUE 20

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2.1 Organisation MPSI - Vue alternative . . . . . . . . . . . . . . . . . . . . 21

1.2.2 Logo MPSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2.3 L’importance des logs pour l’analyse et la prise de décision en temps réel 23

1.3 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4 Contexte et problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.5 Critique des solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.7 Méthodologie de Gestion de Projet . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.7.1 Approches de Gestion de Projet : Agile vs Traditionnelle . . . . . . . . . 27

1.7.2 Choix de la Méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.7.3 Tableau comparatif des trois méthodes . . . . . . . . . . . . . . . . . . . 28

1.7.4 La méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.7.4.1 Définition de Scrum . . . . . . . . . . . . . . . . . . . . . . . . 29

1.7.4.2 Principes clés de Scrum . . . . . . . . . . . . . . . . . . . . . . 29

1.7.4.3 Rôles dans Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4
 TABLE DES MATIÈRES

1.7.5 L’équipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.8 Gestion de projet agile avec Jira et Scrum . . . . . . . . . . . . . . . . . . . . . 30

1.9 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.10 Diagrammes UML globaux du système . . . . . . . . . . . . . . . . . . . . . . . 35

1.10.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . 36

1.10.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . 36

1.11 Partenaire institutionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2 MÉTHODOLOGIE ET PLANIFICATION 39

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.3.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.3.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4 Backlog du produit et la planification . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.6 Gestion de projet avec Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6.1 Vue d’ensemble du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6.2 Suivi des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.6.3 Ticket 1 - Configuration initiale . . . . . . . . . . . . . . . . . . . . . . . 46

2.6.4 Ticket 2 - Développement backend . . . . . . . . . . . . . . . . . . . . . 47

2.6.5 Ticket 3 - Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6.6 Ticket 4 - Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.6.7 Ticket 5 - Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.6.8 Ticket - Code Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.6.9 Ticket - Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.6.10 Ticket - Intégration Python/DB . . . . . . . . . . . . . . . . . . . . . . . 50

2.6.11 Ticket - Site web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.6.12 Ticket - Hébergement web . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.6.13 Tests de base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.6.14 Processus de consultation des logs . . . . . . . . . . . . . . . . . . . . . . 52

TABLE DES MATIÈRES

 TABLE DES MATIÈRES

2.6.15 Vérification des connexions réseau . . . . . . . . . . . . . . . . . . . . . . 53

2.7 Technologies et outils de développement . . . . . . . . . . . . . . . . . . . . . . 54

2.7.1 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.7.2 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3 ARCHITECTURE GÉNÉRALE DU SYSTÈME 57

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.2 Architecture 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3 Architecture technique détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3.1 Composants principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.3.3 Interface IfritConnectTest . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.4 Gestion des versions et applications . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.4.1 Suivi des versions Sony Applications . . . . . . . . . . . . . . . . . . . . 58

3.5 Gestion des stocks et maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5.1 Suivi des stocks de cartes mères PS5 . . . . . . . . . . . . . . . . . . . . 59

3.5.2 Maintenance préventive des câbles testeurs . . . . . . . . . . . . . . . . . 60

3.6 Historique et traçabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.6.1 Historique des cartes mères . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.6.2 Historique des consoles PS5 . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.7 Performance et résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.7.1 Capacité de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.7.2 Temps de réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.7.3 Disponibilité du système . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS 68

4.1 Introduction du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.3 Conception UML du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.3.1 Diagramme des cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . 70

TABLE DES MATIÈRES

 TABLE DES MATIÈRES

4.3.2 Diagramme de séquence - Authentification . . . . . . . . . . . . . . . . . 70

4.3.3 Diagramme de séquence - Consultation des logs . . . . . . . . . . . . . . 73

4.3.4 Interface utilisateur - Accès général . . . . . . . . . . . . . . . . . . . . . 74

4.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 75

4.4.1 Cas d’utilisation : S’authentifier . . . . . . . . . . . . . . . . . . . . . . . 75

4.4.2 Cas d’utilisation : Consulter les logs . . . . . . . . . . . . . . . . . . . . . 75

4.5 Réalisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.5.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.5.2 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.5.3 Fonctionnalités de consultation de base . . . . . . . . . . . . . . . . . . . 77

4.5.4 Interface de recherche par critères . . . . . . . . . . . . . . . . . . . . . . 79

4.5.5 Affichage des résultats de recherche . . . . . . . . . . . . . . . . . . . . . 79

4.5.6 Recherche par numéro de série . . . . . . . . . . . . . . . . . . . . . . . . 80

4.5.7 Interface de connexion initiale . . . . . . . . . . . . . . . . . . . . . . . . 80

4.5.8 Interface d’accueil après connexion . . . . . . . . . . . . . . . . . . . . . 81

4.6 Tests et validation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.6.1 Tests d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.6.2 Tests de consultation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.7 Bilan du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5 SPRINT 2 : FONCTIONNALITÉS AVANCÉES 83

5.1 Introduction du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.2 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3 Conception UML du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3.1 Diagramme des cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . 85

5.3.2 Diagramme de séquence - Consultation des erreurs . . . . . . . . . . . . 86

5.3.3 Diagramme de séquence - Vérification EMC . . . . . . . . . . . . . . . . 86

5.3.4 Diagramme de séquence - Suivi des versions . . . . . . . . . . . . . . . . 86

5.3.5 Diagramme de séquence - Vérification des connexions . . . . . . . . . . . 87

5.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 88

5.4.1 Cas d’utilisation : Consulter les erreurs des tests . . . . . . . . . . . . . . 88

TABLE DES MATIÈRES

 TABLE DES MATIÈRES

5.4.2 Cas d’utilisation : Vérifier la conformité électromagnétique . . . . . . . . 89

5.5 Réalisation du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.5.1 Interface Log Bord-Diag . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.5.2 Interface EMC LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.5.3 Stratégies de test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.5.4 Tests de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.5.5 Résultats de recherche avancée . . . . . . . . . . . . . . . . . . . . . . . . 93

5.5.6 Recherche de logs - Étape 1 . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.5.7 Recherche de logs - Étape 2 . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.8 Recherche de logs - Étape 3 . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.5.9 Recherche de logs - Étape 4 . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.5.10 Recherche par numéro de série - Étape 1 . . . . . . . . . . . . . . . . . . 97

5.5.11 Recherche par numéro de série - Étape 2 . . . . . . . . . . . . . . . . . . 98

5.5.12 Recherche PS5 par numéro de série - Étape 1 . . . . . . . . . . . . . . . 99

5.5.13 Recherche PS5 par numéro de série - Étape 2 . . . . . . . . . . . . . . . 100

5.5.14 Affichage et téléchargement des logs . . . . . . . . . . . . . . . . . . . . . 100

5.5.15 Consultation des logs détaillés . . . . . . . . . . . . . . . . . . . . . . . . 100

5.6 Tests et validation du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.6.1 Tests de diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.6.2 Tests de conformité EMC . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.6.3 Tests de recherche avancée . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.7 Bilan du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6 SPRINT 3 : TESTS ET SIMULATION 103

6.1 Introduction du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.2 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.3 Conception UML du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.3.1 Diagramme des cas d’utilisation du Sprint 3 . . . . . . . . . . . . . . . . 105

6.3.2 Diagramme de séquence - Automatisation des tests . . . . . . . . . . . . 105

6.3.3 Diagramme de séquence - Simulation de scénarios . . . . . . . . . . . . . 106

6.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 106

TABLE DES MATIÈRES

 TABLE DES MATIÈRES

6.4.1 Cas d’utilisation : Automatiser les tests . . . . . . . . . . . . . . . . . . . 106

6.5 Réalisation du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.5.1 Interface QualityCheck2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.5.2 Interface IfritConnectTest . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.6 Tests et validation du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.6.1 Tests d’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.7 Bilan du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7 SPRINT 4 : FINALISATION ET OPTIMISATION 109

7.1 Introduction du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.2 Backlog du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.3 Conception UML du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.3.1 Diagramme des cas d’utilisation du Sprint 4 . . . . . . . . . . . . . . . . 111

7.3.2 Diagramme de séquence - Gestion des versions . . . . . . . . . . . . . . . 111

7.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 111

7.4.1 Cas d’utilisation : Suivre les versions des logiciels . . . . . . . . . . . . . 111

7.5 Réalisation du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.5.1 Suivi des versions Sony Applications . . . . . . . . . . . . . . . . . . . . 112

7.5.2 Gestion des stocks de cartes mères PS5 . . . . . . . . . . . . . . . . . . . 113

7.5.3 Maintenance préventive des câbles testeurs . . . . . . . . . . . . . . . . . 115

7.5.4 Maintenance préventive - Vue supplémentaire . . . . . . . . . . . . . . . 116

7.5.5 Historique des cartes mères - Vue 1 . . . . . . . . . . . . . . . . . . . . . 116

7.5.6 Historique des cartes mères - Vue 2 . . . . . . . . . . . . . . . . . . . . . 117

7.5.7 Historique des cartes mères - Vue 3 . . . . . . . . . . . . . . . . . . . . . 117

7.5.8 Historique des cartes mères - Vue 4 . . . . . . . . . . . . . . . . . . . . . 118

7.5.9 Historique des consoles PS5 - Vue 1 . . . . . . . . . . . . . . . . . . . . . 118

7.5.10 Historique des consoles PS5 - Vue 2 . . . . . . . . . . . . . . . . . . . . . 119

7.5.11 Historique des consoles PS5 - Vue 3 . . . . . . . . . . . . . . . . . . . . . 119

7.6 Tests et validation du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.6.1 Tests de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.6.2 Tests de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

TABLE DES MATIÈRES

 TABLE DES MATIÈRES

7.7 Bilan du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

8 Conclusion Générale 122

TABLE DES MATIÈRES

Liste des tableaux

1.1 Critique des solutions existantes pour la gestion des logs . . . . . . . . . . . . . 24

1.2 Comparaison des méthodes de gestion de projet . . . . . . . . . . . . . . . . . . 28

1.3 Tableau d’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4 Exemple de tickets Jira du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.2 Planification des Sprints du projet de gestion des logs PS5 . . . . . . . . . . . . 44

4.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2 Description du cas d’utilisation "S’authentifier" . . . . . . . . . . . . . . . . . . . 75

4.3 Description du cas d’utilisation "Consulter les logs" . . . . . . . . . . . . . . . . 75

5.1 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.2 Description du cas d’utilisation "Consulter les erreurs des tests" . . . . . . . . . 88

5.3 Description du cas d’utilisation "Vérifier la conformité électromagnétique" . . . . 89

6.1 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.2 Description du cas d’utilisation "Automatiser les tests" . . . . . . . . . . . . . . 106

7.1 Backlog du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.2 Description du cas d’utilisation "Suivre les versions des logiciels" . . . . . . . . . 112

11
Table des figures

0.1 Logo du CNAM - Institution partenaire du projet . . . . . . . . . . . . . . . . . 18

1.1 Logo MPSI - Maintenance Partner Solution International . . . . . . . . . . . . . 21

1.2 Organigramme de MPSI - Maintenance Partner Solution International . . . . . . 22

1.3 Stack technologique utilisée dans le projet de consultation de logs PS5 . . . . . . 25

1.4 Windows Server 2016 - Système d’exploitation serveur . . . . . . . . . . . . . . . 25

1.5 Méthodologie Scrum adoptée pour le développement du projet . . . . . . . . . . 30

1.6 Planning Gantt du projet - Répartition des tâches sur les 4 sprints . . . . . . . . 31

1.7 Visual Studio Code - Environnement de développement pour l’application web . 35

1.8 Diagramme des cas d’utilisation global - Interactions utilisateur-système . . . . . 36

1.9 Diagramme de classes global du système . . . . . . . . . . . . . . . . . . . . . . 37

1.10 Logo du CNAM - Institution partenaire du projet . . . . . . . . . . . . . . . . . 38

2.1 Jira - Vue d’ensemble des tâches du projet . . . . . . . . . . . . . . . . . . . . . 45

2.2 Jira - Suivi des tâches complétées . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.3 Jira - Ticket 1 : Configuration initiale du projet . . . . . . . . . . . . . . . . . . 46

2.4 Jira - Ticket 2 : Développement du backend . . . . . . . . . . . . . . . . . . . . 47

2.5 Jira - Ticket 3 : Développement de l’interface utilisateur . . . . . . . . . . . . . 47

2.6 Jira - Ticket 4 : Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.7 Jira - Ticket 5 : Déploiement et mise en production . . . . . . . . . . . . . . . . 49

2.8 Jira - Ticket : Développement du code Python . . . . . . . . . . . . . . . . . . . 49

2.9 Jira - Ticket : Configuration de la base de données . . . . . . . . . . . . . . . . . 50

2.10 Jira - Ticket : Intégration Python et base de données . . . . . . . . . . . . . . . 50

2.11 Jira - Ticket : Développement du site web . . . . . . . . . . . . . . . . . . . . . 51

2.12 Jira - Ticket : Configuration de l’hébergement web . . . . . . . . . . . . . . . . . 51

2.13 Jira - Tests de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . 52

12
 TABLE DES FIGURES

2.14 Interface de recherche spécialisée par numéro de série (SN) . . . . . . . . . . . . 52

2.15 Workflow complet du processus de consultation des logs . . . . . . . . . . . . . . 53

2.16 Interface de vérification des connexions réseau et diagnostic . . . . . . . . . . . . 53

2.17 MySQL Server - Système de gestion de base de données relationnelle . . . . . . 54

2.18 Python - Langage de programmation pour les scripts de reporting . . . . . . . . 54

2.19 Node.js - Plateforme de développement pour applications web temps réel . . . . 54

2.20 IIS - Serveur web Microsoft pour l’hébergement d’applications . . . . . . . . . . 55

2.21 Windows Server 2016 - Plateforme serveur Microsoft . . . . . . . . . . . . . . . 55

2.22 Visual Studio Code - Environnement de développement intégré . . . . . . . . . . 55

3.1 Interface IfritConnectTest pour la vérification des connexions réseau . . . . . . . 58

3.2 Interface de suivi des versions des applications Sony . . . . . . . . . . . . . . . . 59

3.3 Suivi des versions au démarrage des postes de travail . . . . . . . . . . . . . . . 59

3.4 Interface de suivi des stocks de cartes mères PS5 - Vue 1 . . . . . . . . . . . . . 60

3.5 Interface de suivi des stocks de cartes mères PS5 - Vue 2 . . . . . . . . . . . . . 60

3.6 Interface de suivi de maintenance préventive - Câbles testeurs SONY . . . . . . 61

3.7 Planification de maintenance préventive - Vue détaillée . . . . . . . . . . . . . . 61

3.8 Suivi des interventions de maintenance préventive . . . . . . . . . . . . . . . . . 62

3.9 Historique des cartes mères - Vue générale . . . . . . . . . . . . . . . . . . . . . 63

3.10 Historique des cartes mères - Détails des interventions . . . . . . . . . . . . . . . 63

3.11 Historique des cartes mères - Suivi des modifications . . . . . . . . . . . . . . . 64

3.12 Historique des cartes mères - Statistiques d’utilisation . . . . . . . . . . . . . . . 64

3.13 Historique des consoles PS5 - Vue générale . . . . . . . . . . . . . . . . . . . . . 65

3.14 Historique des consoles PS5 - Détails des tests . . . . . . . . . . . . . . . . . . . 65

3.15 Historique des consoles PS5 - Interventions et maintenance . . . . . . . . . . . . 66

4.1 Diagramme des cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . 70

4.2 Diagramme de séquence - Processus d’authentification . . . . . . . . . . . . . . . 71

4.3 Sprint 1 - Authentification et base de données . . . . . . . . . . . . . . . . . . . 72

4.4 Sprint 2 - Interface web et consultation . . . . . . . . . . . . . . . . . . . . . . . 72

4.5 Backlogs des sprints 1 et 2 - Planification des fonctionnalités . . . . . . . . . . . 72

4.6 Sprint 3 - Tests et automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . 73

TABLE DES FIGURES

 TABLE DES FIGURES

4.7 Sprint 4 - Finalisation et déploiement . . . . . . . . . . . . . . . . . . . . . . . . 73

4.8 Backlogs des sprints 3 et 4 - Finalisation du projet . . . . . . . . . . . . . . . . . 73

4.9 Diagramme de séquence - Consultation des logs . . . . . . . . . . . . . . . . . . 74

4.10 Interface utilisateur - Accès général au système . . . . . . . . . . . . . . . . . . . 74

4.11 Interface d’authentification principale . . . . . . . . . . . . . . . . . . . . . . . . 76

4.12 Processus d’authentification avec validation . . . . . . . . . . . . . . . . . . . . 76

4.13 Interface d’accueil avec navigation vers les fonctionnalités . . . . . . . . . . . . . 77

4.14 Interface de critères de recherche de base . . . . . . . . . . . . . . . . . . . . . . 78

4.15 Interface de recherche par critères spécifiques . . . . . . . . . . . . . . . . . . . . 79

4.16 Interface d’affichage des résultats de recherche . . . . . . . . . . . . . . . . . . . 80

4.17 Interface de recherche par numéro de série . . . . . . . . . . . . . . . . . . . . . 80

4.18 Interface de connexion initiale du système . . . . . . . . . . . . . . . . . . . . . 81

4.19 Interface d’accueil - Tableau de bord principal . . . . . . . . . . . . . . . . . . . 81

5.1 Diagramme des cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . . . . 85

5.2 Diagramme de séquence - Consultation des erreurs . . . . . . . . . . . . . . . . . 86

5.3 Diagramme de séquence - Vérification de conformité électromagnétique . . . . . 86

5.4 Diagramme de séquence - Suivi des versions logicielles . . . . . . . . . . . . . . . 87

5.5 Diagramme de séquence - Vérification des connexions réseau . . . . . . . . . . . 87

5.6 Interface Log Bord-Diag - Consultation des erreurs . . . . . . . . . . . . . . . . 90

5.7 Interface EMC LOG - Vérification de conformité . . . . . . . . . . . . . . . . . . 91

5.8 Automatisation des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.9 Simulation de scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.10 Stratégies de test fonctionnel du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . 92

5.11 Vérification des connexions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.12 Performance consultation logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.13 Interface de résultats de recherche avec options de téléchargement . . . . . . . . 94

5.14 Recherche de logs - Sélection des critères de base . . . . . . . . . . . . . . . . . . 95

5.15 Recherche de logs - Affichage des résultats . . . . . . . . . . . . . . . . . . . . . 96

5.16 Recherche de logs - Détails des résultats . . . . . . . . . . . . . . . . . . . . . . 97

5.17 Recherche de logs - Filtrage avancé . . . . . . . . . . . . . . . . . . . . . . . . . 97

TABLE DES FIGURES

 TABLE DES FIGURES

5.18 Recherche par numéro de série - Sélection du SN . . . . . . . . . . . . . . . . . . 98

5.19 Recherche par numéro de série - Résultats . . . . . . . . . . . . . . . . . . . . . 99

5.20 Recherche PS5 par numéro de série - Sélection . . . . . . . . . . . . . . . . . . . 99

5.21 Recherche PS5 par numéro de série - Résultats . . . . . . . . . . . . . . . . . . . 100

5.22 Interface d’affichage et téléchargement des logs . . . . . . . . . . . . . . . . . . . 100

5.23 Interface de consultation détaillée des logs . . . . . . . . . . . . . . . . . . . . . 101

6.1 Diagramme des cas d’utilisation du Sprint 3 . . . . . . . . . . . . . . . . . . . . 105

6.2 Diagramme de séquence - Automatisation des tests . . . . . . . . . . . . . . . . 105

6.3 Diagramme de séquence - Simulation de scénarios . . . . . . . . . . . . . . . . . 106

6.4 Interface QualityCheck2 pour les testeurs . . . . . . . . . . . . . . . . . . . . . . 107

6.5 Interface IfritConnectTest pour la vérification des connexions . . . . . . . . . . . 107

7.1 Diagramme des cas d’utilisation du Sprint 4 . . . . . . . . . . . . . . . . . . . . 111

7.2 Diagramme de séquence - Gestion des versions logicielles . . . . . . . . . . . . . 111

7.3 Interface de suivi des versions des applications Sony . . . . . . . . . . . . . . . . 112

7.4 Suivi des versions au démarrage des postes de travail . . . . . . . . . . . . . . . 113

7.5 Interface de suivi des stocks de cartes mères PS5 - Vue 1 . . . . . . . . . . . . . 113

7.6 Interface de suivi des stocks de cartes mères PS5 - Vue 2 . . . . . . . . . . . . . 114

7.7 Suivi préventif câbles testeurs SONY . . . . . . . . . . . . . . . . . . . . . . . . 115

7.8 Suivi préventif câbles testeurs SONY 2 . . . . . . . . . . . . . . . . . . . . . . . 115

7.9 Maintenance préventive - Câbles testeurs SONY . . . . . . . . . . . . . . . . . . 115

7.10 Maintenance préventive - Vue supplémentaire des câbles testeurs . . . . . . . . . 116

7.11 Historique des cartes mères - Vue générale . . . . . . . . . . . . . . . . . . . . . 117

7.12 Historique des cartes mères - Détails . . . . . . . . . . . . . . . . . . . . . . . . 117

7.13 Historique des cartes mères - Vue détaillée . . . . . . . . . . . . . . . . . . . . . 118

7.14 Historique des cartes mères - Vue complète . . . . . . . . . . . . . . . . . . . . . 118

7.15 Historique des consoles PS5 - Vue générale . . . . . . . . . . . . . . . . . . . . . 119

7.16 Historique des consoles PS5 - Détails . . . . . . . . . . . . . . . . . . . . . . . . 119

7.17 Historique des consoles PS5 - Vue complète . . . . . . . . . . . . . . . . . . . . . 120

TABLE DES FIGURES

Liste des acronymes

- SQL : Langage de requêtes structurées (Structured Query Language)

- SGBD : Système de Gestion de Base de Données
- UML : Langage de Modélisation Unifié (Unified Modeling Language)
- API : Interface de Programmation d’Applications (Application Programming Interface)
- IIS : Services d’Information Internet (Internet Information Services)
- OS : Système d’Exploitation (Operating System)
- Scrum : Cadre agile de gestion de projet
- RAM : Mémoire vive (Random Access Memory)
- MCB : Carte de Contrôle de la Carte Mère (Motherboard Control Board)
- EMC : Compatibilité Électromagnétique (ElectroMagnetic Compatibility)
- SN : Numéro de Série (Serial Number)
- UI : Interface Utilisateur (User Interface)
- CLI : Interface en Ligne de Commande (Command Line Interface)
- IDE : Environnement de Développement Intégré (Integrated Development Environment)
Introduction générale

Figure 0.1 – Logo du CNAM - Institution partenaire du projet

Imaginez une usine où chaque seconde compte, où une panne non détectée peut coûter des
milliers d’euros, et où les équipes de production doivent prendre des décisions critiques en
quelques minutes. C’est le défi quotidien que j’ai rencontré lors de mon stage au sein de l’orga-
nisation MPSI. Les logs de production, ces précieuses sources d’information, étaient dispersés
sur différents postes, difficiles d’accès, et souvent analysés trop tard pour être vraiment utiles.

C’est de cette frustration qu’est né ce projet. J’ai rapidement compris que le problème ne
résidait pas dans le manque de données, mais dans l’absence d’un système capable de les rendre
accessibles et exploitables en temps réel. Les équipes Méthode, Qualité et Production avaient
besoin d’une solution qui transforme ces logs bruts en véritables outils d’aide à la décision.

Ce mémoire raconte l’histoire de ce défi technique et humain. J’ai choisi de développer une
architecture 2-tiers qui ne se contente pas de collecter des données, mais qui les transforme en
informations actionnables. La solution s’appuie sur des technologies que j’ai appris à maîtri-
ser : MySQL pour sa fiabilité éprouvée, Python pour sa flexibilité dans l’automatisation, et
Node.js pour sa capacité à créer des interfaces réactives et intuitives.

Ce mémoire suit le parcours de ce projet, de l’idée initiale jusqu’à sa réalisation concrète. J’ai
organisé le contenu pour que vous puissiez suivre ma réflexion et mes décisions à chaque étape :

- Chapitre 1 : Contexte et problématique

Je commence par vous plonger dans le contexte réel de l’usine MPSI et vous expliquer
pourquoi ce projet était si urgent. Vous découvrirez les défis quotidiens des équipes de
production et pourquoi les solutions existantes ne répondaient pas à leurs besoins.
- Chapitre 2 : Méthodologie Scrum et planification
Ici, je vous raconte comment j’ai structuré ce projet complexe. J’ai choisi l’approche
Scrum, non pas par hasard, mais parce qu’elle permettait de livrer des fonctionnalités
utiles rapidement tout en gardant la flexibilité nécessaire face aux imprévus.
- Chapitre 3 : Architecture générale du système
C’est le moment où j’ai dû faire des choix techniques cruciaux. Je vous présente les dia-
grammes UML généraux (cas d’utilisation et classes) qui définissent la structure complète
du système et ses principales fonctionnalités.

18
 Introduction générale

- Chapitre 4 : Sprint 1 - Authentification et consultation des logs

Premier sprint : la base du système. Je vous raconte comment j’ai implémenté l’authenti-
fication sécurisée et les premières fonctionnalités de consultation des logs. Chaque sprint
suit la même structure : introduction, backlog, conception UML, description textuelle,
réalisation et tests.
- Chapitre 5 : Sprint 2 - Fonctionnalités avancées
Deuxième sprint : l’évolution. Ajout des fonctionnalités de diagnostic, de conformité élec-
tromagnétique et de recherche avancée. Vous verrez comment chaque sprint construit sur
le précédent.
- Chapitre 6 : Sprint 3 - Tests et simulation
Troisième sprint : l’automatisation. Développement des modules de test automatique,
simulation de scénarios et téléchargement des données. La complexité augmente mais la
méthodologie Scrum reste notre guide.
- Chapitre 7 : Sprint 4 - Finalisation et optimisation
Sprint final : la perfection. Optimisation des performances, gestion des versions, vérifica-
tion des connexions et préparation au déploiement. Le système est maintenant prêt pour
la production.

Cette structure Scrum vous permettra de comprendre comment chaque sprint a contribué à la
construction progressive du système, avec ses propres défis, solutions et résultats.

Page 19
Chapitre 1

CONTEXTE ET PROBLÉMATIQUE

20
 ÉTUDE DE PROJET

1.1 Introduction

La gestion des logs de production et de test est cruciale pour assurer la continuité des opérations
dans un environnement industriel. L’accès rapide et efficace à ces logs permet de détecter,
analyser et résoudre les pannes, améliorant ainsi la productivité et la fiabilité des processus.
Cependant, l’absence d’un accès en temps réel aux logs représente un défi majeur qui peut
ralentir les interventions et impacter la qualité de la production. Ce projet vise à concevoir et
à implémenter une architecture 2-tiers pour un système de consultation de logs en temps réel,
répondant aux besoins d’une analyse rapide et centralisée des données critiques.

1.2 Présentation de l’entreprise

MPSI (Maintenance Partner Solution International) est une entreprise spécialisée dans la main-
tenance industrielle, l’innovation technologique et la gestion de la qualité. Forte d’une organi-
sation structurée et d’une équipe pluridisciplinaire, MPSI place l’efficacité, la réactivité et la
satisfaction client au cœur de sa stratégie. L’entreprise s’appuie sur une organisation hiérar-
chique claire, favorisant la collaboration entre les différents pôles : direction, production, qualité,
IT, R&D, support technique, etc. Cette structure permet d’assurer une gestion optimale des
projets et une adaptation rapide aux besoins du marché industriel.

1.2.1 Organisation MPSI - Vue alternative

Vue alternative de l’organisation MPSI montrant les relations entre les différents services :

1.2.2 Logo MPSI

Le logo officiel de l’entreprise MPSI :

Figure 1.1 – Logo MPSI - Maintenance Partner Solution International

Présentation de l’entreprise Page 21

 ÉTUDE DE PROJET

Figure 1.2 – Organigramme de MPSI - Maintenance Partner Solution International

Présentation de l’entreprise Page 22

 ÉTUDE DE PROJET

1.2.3 L’importance des logs pour l’analyse et la prise de décision en

temps réel

Dans un contexte industriel, la capacité à accéder et à analyser les logs en temps réel est un
facteur clé de performance. Les logs permettent de :
- Détecter rapidement les anomalies et les pannes sur les lignes de production ;
- Prendre des décisions immédiates pour corriger les dysfonctionnements, réduisant ainsi
les temps d’arrêt ;
- Optimiser la traçabilité et la qualité des produits finis ;
- Générer des rapports fiables pour l’amélioration continue et l’audit.
L’accès instantané aux informations issues des logs se traduit par un gain de temps considé-
rable en production et une efficacité accrue dans la prise de décision. Cela permet aux équipes
Méthode, Qualité et Production de réagir de manière proactive, d’anticiper les problèmes et
d’assurer la continuité des opérations.

1.3 Cadre général

Le projet s’inscrit dans le cadre d’une amélioration des processus de gestion des logs dans une
entreprise de production technologique. Cette entreprise gère plusieurs postes de production et
de test qui génèrent des logs pour diagnostiquer les pannes et optimiser le flux de production.
Actuellement, l’absence d’un système centralisé et en temps réel complique l’analyse et le traite-
ment rapide des données. Le développement de ce projet repose sur l’utilisation de technologies
telles que MySQL, Python et Node.js pour automatiser et visualiser l’accès aux logs.

1.4 Contexte et problématique

Les systèmes de production modernes s’appuient sur des données de diagnostic pour maintenir
leur performance. Dans le contexte actuel, l’accès aux logs de test n’est pas immédiat, ce qui
limite la capacité des équipes à réagir rapidement face aux incidents. L’absence de consultation
en temps réel complique la détection précoce des problèmes et entraîne des délais de résolution
prolongés, impactant négativement la production. La problématique centrale de ce projet est
donc de surmonter ces limitations par la mise en place d’une solution qui permette un accès
rapide et efficace aux logs, offrant ainsi aux équipes Méthode, Qualité et Production la capacité
d’améliorer la prise de décision.

Contexte et problématique Page 23

 ÉTUDE DE PROJET

1.5 Critique des solutions existantes

Dans cette section, nous examinerons les solutions actuellement utilisées dans les entreprises
pour la gestion des logs et fournirons une analyse critique de celles-ci.

Solution Avantages Inconvénients

Fichiers tex- Facile à mettre en œuvre : Les fi- Pas de consultation en temps
te/Excel chiers texte et Excel sont des solu- réel : Les utilisateurs doivent ou-
tions accessibles et peu coûteuses, vrir et manipuler les fichiers ma-
permettant une gestion simple nuellement, ce qui ralentit le pro-
des logs. Flexibilité : Adaptable cessus de prise de décision.
pour des volumes de données ré- Limité aux petits volumes : In-
duits et analyses de base. efficace pour gérer de grands en-
sembles de données, entraînant
des problèmes de performance et
de navigation.
Google Sheets Gratuit et collaboratif : Permet Limitations de performance : Ra-
un accès partagé et des mises à lentissements et difficultés de ges-
jour en temps réel par plusieurs tion pour de grands volumes de
utilisateurs. Simple à utiliser : données.
Gestion de données basique avec Sécurité insuffisante : Protection
tri et filtrage. des données sensibles limitée.
Manque de fonctionnalités avan-
cées : Ne permet pas une consul-
tation en temps réel adaptée à un
usage industriel critique.
Splunk Fonctionnalités avancées : Outils Coût élevé : Peut représenter
de visualisation de logs robustes un investissement important, ren-
et puissants pour des analyses dant son accès difficile pour les
approfondies. Extensibilité : Ca- petites et moyennes entreprises.
pable de gérer de grands volumes Complexité de mise en œuvre :
de données en temps réel. Nécessite des compétences tech-
niques avancées pour l’installa-
tion et la configuration.
Elastic Stack Open-source et flexible : Offre une Mise en œuvre complexe : De-
grande adaptabilité et des possi- mande une expertise technique
bilités de personnalisation. Puis- pour la configuration et la main-
sance de recherche : Permet des tenance.
recherches complexes et un accès Ressources élevées : Peut néces-
en temps réel aux logs. siter des infrastructures robustes
pour fonctionner de manière opti-
male.

Table 1.1 – Critique des solutions existantes pour la gestion des logs

Critique des solutions existantes Page 24

 ÉTUDE DE PROJET

1.6 Solution proposée

Pour répondre aux défis identifiés dans la gestion des logs, ce projet propose la mise en place
d’une architecture 2-tiers. Cette architecture vise à centraliser, automatiser et visualiser les
données de logs en temps réel, afin de faciliter l’analyse et la prise de décision. Les principaux
composants de la solution sont décrits ci-dessous :

- MySQL : Utilisé pour la centralisation et la gestion des logs dans une base de données
structurée. MySQL permet le stockage sécurisé et l’organisation efficace des logs, facilitant
ainsi leur récupération rapide.
- Python : Outil principal pour l’automatisation de la collecte et du traitement des logs.
Python est choisi pour sa flexibilité et sa capacité à gérer des scripts complexes qui
minimisent les interventions manuelles et augmentent l’efficacité.
- Node.js : Utilisé pour l’affichage des logs en temps réel via une interface web. Cette tech-
nologie permet de créer une application web interactive et réactive, offrant aux utilisateurs
une consultation rapide et fluide des données de logs.

L’objectif de cette solution est de fournir un système capable de capturer, stocker et afficher les
logs de manière efficace tout en offrant des options de recherche avancée. Les fonctionnalités
incluent la recherche par numéro de série (SN), date, poste de test et code de panne, permettant
aux équipes de production et de qualité d’identifier rapidement les pannes et de prendre des
décisions informées.

(a) Python - Langage (b) Node.js - Runtime (c) MySQL - Système

de programmation JavaScript pour le ser- de gestion de base de (d) IIS - Serveur web
pour l’automatisation veur web données Microsoft

Figure 1.3 – Stack technologique utilisée dans le projet de consultation de logs PS5

Figure 1.4 – Windows Server 2016 - Système d’exploitation serveur

Solution proposée Page 25

 ÉTUDE DE PROJET

Automatisation de l’insertion des logs : script Python dédié

L’automatisation de la collecte et de l’insertion des logs dans la base de données centrale est
assurée par un script Python robuste et sécurisé, développé spécifiquement pour le projet. Ce
script joue un rôle clé dans l’architecture globale, garantissant la traçabilité, la fiabilité et la
disponibilité des données pour l’analyse en temps réel.

Fonctionnalités principales du script :

- Lecture automatique des fichiers logs : le script parcourt les répertoires sources
(JigLog, NgLog) sur chaque poste de production pour détecter les nouveaux fichiers à
traiter.
- Vérification d’unicité et de traitement : avant toute insertion, il vérifie si le log
(ou sa version alternative) existe déjà dans la base ou a déjà été traité, évitant ainsi les
doublons.
- Connexion sécurisée à MySQL : chaque log est inséré dans la table appropriée, avec
enregistrement du nom du poste, du fichier, du contenu et de la date.
- Gestion des accès concurrents : un fichier de verrouillage (lock file) empêche l’exécu-
tion simultanée de plusieurs instances du script sur le même poste.
- Journalisation des erreurs et des fichiers verrouillés : tous les problèmes rencontrés
(fichiers inaccessibles, erreurs de lecture, etc.) sont consignés dans un fichier dédié avec
horodatage.
- Robustesse et nettoyage automatique : gestion des exceptions, fermeture propre des
connexions, suppression automatique du lock file à la sortie.
Rôle dans l’architecture globale : Ce script constitue le lien entre les postes de production
(où sont générés les logs) et la base de données centrale. Il garantit que chaque événement de
production est tracé, stocké et disponible pour l’analyse, l’affichage et la prise de décision en
temps réel via l’interface web.

Solution proposée Page 26

 ÉTUDE DE PROJET

Extrait de code commenté :

Listing 1.1 – Extrait du script d’insertion des logs dans la base MySQL
# Connexion l a b a s e de d o n n e s MySQL
c o n n e c t i o n = mysql . c o n n e c t o r . c o n n e c t (
h o s t=db_host ,
d a t a b a s e=db_name ,
u s e r=db_user ,
password=db_password
)
# I n s e r t i o n d ’ un l o g dans l a t a b l e c i b l e
insert_query = f """
INSERT INTO { table_name } ( host_name , log_file_name , l o g _ c o n t e n t , c r e a t e d _ a t )
VALUES (%s , %s , %s , NOW( ) )
"""
c u r s o r . e x e c u t e ( i n s e r t _ q u e r y , ( host_name , l o g _ f i l e , l o g _ c o n t e n t ) )
c o n n e c t i o n . commit ( )

Sécurité et fiabilité :
- Fichier de verrouillage : évite les conflits d’accès concurrents.
- Vérification de l’état des fichiers : saute les fichiers en cours d’utilisation par d’autres
processus.
- Journalisation des erreurs : chaque problème est consigné avec un message explicite et
un timestamp.
Ce composant logiciel est essentiel pour garantir l’intégrité et la disponibilité des données, et il
s’intègre parfaitement dans le pipeline global du projet.

1.7 Méthodologie de Gestion de Projet

La gestion de projet comprend toutes les actions qui permettent de garantir la planification
et la réalisation efficace de notre projet dans les délais prévus, tout en atteignant les objectifs
fixés.

Avant le début de notre projet, nous optons pour une approche adéquate afin d’assurer le succès
de notre gestion de projet.

1.7.1 Approches de Gestion de Projet : Agile vs Traditionnelle

En matière de gestion de projet, deux approches se distinguent : l’approche Agile et l’approche

traditionnelle.

L’approche Agile met l’accent sur l’adaptabilité, la collaboration et l’itération. Les équipes
travaillent par cycles courts, appelés "sprints", où elles se concentrent sur des objectifs spécifiques
et réalisent des livraisons fréquentes de produits fonctionnels.

En revanche, l’approche traditionnelle suit une approche linéaire et séquentielle, avec une pla-
nification détaillée dès le début du projet. Elle implique moins d’itération et de flexibilité par
rapport à l’approche Agile.

Méthodologie de Gestion de Projet Page 27

 ÉTUDE DE PROJET

Chaque approche présente ses avantages et est adaptée à des contextes de projet spécifiques.
Dans la partie suivante, nous choisirons la méthode qui convient le mieux à notre projet en
tenant compte de ses spécificités et de nos besoins.

1.7.2 Choix de la Méthode

Pour améliorer la gestion de notre projet, il est essentiel d’adopter une méthode appropriée.

Cela nous permettra d’organiser et de planifier efficacement l’exécution de nos activités. Il existe
différentes méthodes de gestion de projet parmi lesquelles nous comparerons et choisirons celle
qui convient le mieux à notre projet. Nous nous concentrerons sur une comparaison entre les
méthodes Waterfall, V-cycle et Scrum, largement utilisées dans les entreprises.

La méthode Waterfall, également connue sous le nom de modèle en cascade, consiste à suivre
une série d’étapes préétablies séquentiellement, où chaque étape mène à la suivante.

La méthode V-cycle englobe toutes les étapes du cycle de développement d’un produit ou d’un
logiciel.

Quant à la méthode Scrum, il s’agit d’une approche agile dédiée à la gestion de projet, axée sur
l’itération, la priorisation des tâches, la collaboration d’équipe et l’adaptation au changement.

1.7.3 Tableau comparatif des trois méthodes

Méthode Cycle en cascade Cycle en V Scrum (Agile)

Focus Planification et Vérification et Valida- Itératif et Adaptable
Contrôle tion
Flexibilité Faible Modérée Élevée
Travail d’équipe Moins d’accent Plus pendant la Véri- Fort Accent Tout au
fication Long
Avantages Facile à comprendre, Améliore le contrôle S’adapte aux exi-
processus discipliné qualité, simple à gences changeantes,
mettre en œuvre améliore la communi-
cation
Inconvénients Difficile à adapter Moins flexible, com- Risque de dérapage
aux changements, munication limitée de la portée, nécessite
nécessite une clarté entre parties pre- une équipe expérimen-
des exigences upfront nantes tée, des tâches non
claires peuvent entraî-
ner des imprécisions

Table 1.2 – Comparaison des méthodes de gestion de projet

Méthodologie de Gestion de Projet Page 28

 ÉTUDE DE PROJET

Après avoir examiné ce tableau comparatif des trois méthodes, nous avons choisi d’adopter
la méthode agile Scrum, car elle correspond parfaitement aux besoins spécifiques de notre
projet. D’une part, cette méthode nous permet d’établir une planification basée sur des jalons
clairement définis. D’autre part, elle facilite l’atteinte des objectifs du projet en se concentrant
sur les fonctionnalités qui apportent le plus de valeur ajoutée.

1.7.4 La méthode Scrum

1.7.4.1 Définition de Scrum

Scrum[?] est une approche flexible et collaborative de la gestion de projet qui met l’accent sur
le développement itératif et incrémental. Il met l’accent sur la livraison de produits à forte
valeur ajoutée grâce à des itérations courtes et limitées dans le temps appelées sprints, au
cours desquelles des équipes pluridisciplinaires travaillent ensemble pour livrer un incrément de
produit potentiellement livrable à la fin de chaque sprint.

1.7.4.2 Principes clés de Scrum

• Transparence : Tous les aspects du processus doivent être visibles et compris par
toutes les parties prenantes.

• Inspection : Le progrès vers les objectifs doit être régulièrement inspecté pour iden-
tifier les variations indésirables.

• Adaptation : Si une inspection révèle un écart par rapport à l’objectif, des ajustements
doivent être effectués pour minimiser les écarts.

1.7.4.3 Rôles dans Scrum

• Product Owner : Le Product Owner est responsable de maximiser la valeur du

produit et du travail de l’équipe de développement. Il définit les éléments du Product Backlog
et les priorise en fonction de la valeur qu’ils apportent au produit.

• Scrum Master : Le Scrum Master est responsable de s’assurer que l’équipe Scrum
comprend et respecte les valeurs, les pratiques et les règles de Scrum. Il aide l’équipe à résoudre
les problèmes et à améliorer continuellement son efficacité.

• Équipe de développement : L’équipe de développement est responsable de livrer

régulièrement des fonctionnalités de produit utilisables. Elle est auto-organisée et pluridiscipli-
naire, et elle s’engage à atteindre les objectifs du sprint et à respecter les normes de qualité
convenues.

Voici une figure 1.2 représentant les éléments clés de la méthode Scrum utilisée dans la gestion
de projet agile.

Méthodologie de Gestion de Projet Page 29

 ÉTUDE DE PROJET

Figure 1.5 – Méthodologie Scrum adoptée pour le développement du projet

1.7.5 L’équipe du projet

Ce tableau d’équipe 1.3, basé sur la méthode Scrum, est établi en accord avec

LATECH, afin de définir les acteurs et leurs rôles pour optimiser la collaboration et la gestion
de projet.

Acteur Rôle
Responsable du projet Product Owner
Chef de projet Scrum Master
Bilel Souidi Équipe

Table 1.3 – Tableau d’équipe

1.8 Gestion de projet agile avec Jira et Scrum

Pour piloter le projet SOFT_MPSI_Projet_LogSPS5, l’équipe a adopté la méthodologie Scrum,

soutenue par l’outil Jira pour la gestion des tâches, la planification des sprints et le suivi
de l’avancement. Cette approche a permis une organisation efficace, une visibilité sur l’état
d’avancement et une réactivité face aux imprévus.

Gestion de projet agile avec Jira et Scrum Page 30

 ÉTUDE DE PROJET

Planification des sprints et tickets Jira

La planification du projet s’est articulée autour de quatre sprints principaux, chacun regroupant
des tickets Jira (PL-1 à PL-18) correspondant aux différentes étapes du développement.

Sprint 1 (1 Décembre 2024 - 14 Décembre 2024)

- Objectif : Mise en place de l’infrastructure de base de données et développement initial
du script Python pour l’insertion des logs.
- Tickets :
◦ PL-1 : Installation et configuration d’un serveur base de données (MySQL 8)
◦ PL-2 : Réalisation d’un code Python pour l’insertion des logs au base de données
◦ PL-5 : Projet : Logs PS5
◦ PL-7, PL-8 : Code Python + Table base de données
- Équipe : Bilet Souidi
- Statut : Toutes les tâches marquées comme « Terminée »

Figure 1.6 – Planning Gantt du projet - Répartition des tâches sur les 4 sprints

Sprint 2 (15 Décembre 2024 - 28 Décembre 2024)

- Objectif : Développement et déploiement de l’interface web pour la gestion des logs, et
premiers tests fonctionnels.
- Tickets :
◦ PL-3 : Développement d’une interface web (JavaScript, CSS, HTML, SQL) pour
l’affichage, recherche et téléchargement des logs
◦ PL-4 : Hébergement de l’interface web au niveau d’un serveur
◦ PL-6 : Test du « irftConnectTest » demandé par SONY sur tous les postes
- Équipe : Bilet Souidi, Bilel Bouani
- Statut : Majoritairement « Terminée », certains tests en cours
Sprint 3 (29 Décembre 2024 - 11 Janvier 2025)
- Objectif : Développement avancé de l’application, affichage par poste, tests de compati-
bilité des versions.
- Tickets :

Gestion de projet agile avec Jira et Scrum Page 31

 ÉTUDE DE PROJET

◦ PL-9 : Affichage par host

◦ PL-10 : Test du version Maos à travers les applications SUI (MCR et PS4-PS5)
◦ PL-11 : Modifications SUI + Affichage + Table base de données
◦ PL-12 : Test unitaire du fonctionnement et Affichage
◦ PL-13 : Duplications sous tous les postes productions
- Équipe : Bilet Souidi
- Statut : Tâches « Terminée » et d’autres en attente
Sprint 4 (12 Janvier 2025 - 25 Janvier 2025)
- Objectif : Finalisation des tests de version, développement de l’outil de vérification en
C#, et automatisation du déploiement.
- Tickets :
◦ PL-14 : Test de version du Mapps au démarrage de tous les postes
◦ PL-15 : Application + Script + Affichage
◦ PL-16 : Développement de l’application « vérifversion » en C#
◦ PL-17 : Réalisation des Script Batch de lancement des applications SONY
◦ PL-18 : Test unitaire du fonctionnement et Affichage
- Équipe : Bilet Souidi, Ichrak Elmay
- Statut : Certaines tâches « Terminée », d’autres en cours ou à faire

Exemples de tickets Jira et backlog détaillé

Le backlog du projet a été structuré autour de tickets Jira, chacun correspondant à une fonc-
tionnalité, une tâche ou un test à réaliser. Voici un extrait représentatif :

Gestion de projet agile avec Jira et Scrum Page 32

 ÉTUDE DE PROJET

ID Titre Description Statut Responsable

PL-1 Installation MySQL Installation et configuration Terminée Bilet Souidi S
d’un serveur MySQL 8
PL-2 Script Python logs Développement d’un script Terminée Bilet Souidi S
Python pour l’insertion des
logs
PL-3 Interface web logs Développement d’une inter- Terminée Bilet Souidi S
face web pour l’affichage et
la recherche des logs
PL-4 Hébergement web Hébergement de l’interface Terminée Bilet Souidi S
web sur un serveur dédié
PL-5 Projet Logs PS5 Initialisation du projet et Terminée Bilet Souidi S
documentation
PL-6 Test irftConnectTest Test de connectivité de- En cours Bilet Souidi S
mandé par SONY sur tous
les postes
PL-7 Table base de données Création des tables néces- Terminée Bilet Souidi S
saires pour les logs
PL-8 Table base de données Optimisation des tables Terminée Bilet Souidi S
pour la performance
PL-9 Affichage par host Développement de l’affi- À faire Bilet Souidi S
chage par poste
PL-10 Test version Maos Test de version sur applica- À faire Bilet Souidi S
tions SUI (MCR, PS4-PS5)
PL-11 Modifications SUI Modifications de l’interface À faire Bilet Souidi S
et de la base de données
PL-12 Test unitaire Test unitaire du fonctionne- À faire Bilet Souidi S
ment et affichage
PL-13 Duplications postes Duplication de la solution À faire Bilet Souidi S
sur tous les postes de pro-
duction
PL-14 Test version Mapps Test de version du Mapps À faire Bilet Souidi, Ichrak Elmay S
au démarrage
PL-15 Application + Script Développement de l’appli- À faire Bilet Souidi S
cation et des scripts d’affi-
chage
PL-16 Vérifversion C# Développement de l’appli- À faire Bilet Souidi S
cation « vérifversion » en
C#
PL-17 Script Batch SONY Réalisation des scripts À faire Bilet Souidi S
batch pour le lancement
des applications SONY
PL-18 Test unitaire final Test unitaire du fonctionne- À faire Bilet Souidi S
ment et affichage final

Table 1.4 – Exemple de tickets Jira du projet

Gestion de projet agile avec Jira et Scrum Page 33

 ÉTUDE DE PROJET

Exemples de user stories et sous-tâches

- User story PL-2 : En tant que développeur, je veux un script Python qui insère au-
tomatiquement les logs dans la base de données afin d’assurer la traçabilité en temps
réel.
◦ Sous-tâche 1 : Écrire le script d’insertion.
◦ Sous-tâche 2 : Tester l’insertion sur un jeu de données réel.
◦ Sous-tâche 3 : Corriger les éventuels bugs et documenter le code.
- User story PL-3 : En tant qu’utilisateur, je veux une interface web pour consulter et
télécharger les logs par poste, date, SN, etc.
◦ Sous-tâche 1 : Concevoir le design de l’interface.
◦ Sous-tâche 2 : Développer le backend (requêtes SQL).
◦ Sous-tâche 3 : Intégrer le frontend (HTML/CSS/JS).
◦ Sous-tâche 4 : Effectuer des tests utilisateurs.

Workflow Jira du projet

Le workflow Jira utilisé pour ce projet suit le schéma classique :

- À faire (To Do) : Tâches à réaliser
- En cours (In Progress) : Tâches en développement ou en test
- Terminée (Done) : Tâches finalisées et validées

Rôles Scrum dans le projet

- Product Owner : Responsable de la définition des besoins et de la priorisation du

backlog (Bilet Souidi)
- Scrum Master : Garant de la méthodologie et du bon déroulement des sprints (Bilel
Bouani)
- Développeurs : Réalisation technique des tâches (Bilet Souidi, Ichrak Elmay)

Synthèse de la planification Scrum et diagramme de Gantt

La planification du projet SOFT_MPSI_Projet_LogSPS5 s’est appuyée sur une organisation en

quatre sprints, chacun comportant des tâches précises, des dates de réalisation et des livrables
illustrés par des captures d’écran.

1.9 Environnement de développement

L’environnement de développement du projet a été conçu pour assurer une productivité opti-
male et une collaboration efficace entre les membres de l’équipe. L’utilisation d’outils modernes
et adaptés aux besoins du projet a été un facteur clé de succès.

Environnement de développement Page 34

 ÉTUDE DE PROJET

Figure 1.7 – Visual Studio Code - Environnement de développement pour l’application web

1.10 Diagrammes UML globaux du système

Pour assurer une conception claire et une implémentation cohérente du système, deux dia-
grammes UML globaux ont été élaborés. Ces diagrammes servent de base pour la compréhension
des interactions entre les différents composants du système.

Diagrammes UML globaux du système Page 35

 ÉTUDE DE PROJET

1.10.1 Diagramme des cas d’utilisation global

Ce diagramme présente l’ensemble des fonctionnalités du système et les interactions avec les
différents acteurs :

Figure 1.8 – Diagramme des cas d’utilisation global - Interactions utilisateur-système

1.10.2 Diagramme de classes global

Ce diagramme présente la structure des classes principales du système et leurs relations :

Diagrammes UML globaux du système Page 36

 ÉTUDE DE PROJET

Figure 1.9 – Diagramme de classes global du système

Diagrammes UML globaux du système Page 37

 ÉTUDE DE PROJET

1.11 Partenaire institutionnel

Le projet a été réalisé en collaboration avec le CNAM (Conservatoire National des Arts et
Métiers), institution partenaire qui a apporté son expertise et son soutien tout au long du
développement.

Figure 1.10 – Logo du CNAM - Institution partenaire du projet

Partenaire institutionnel Page 38

Chapitre 2

MÉTHODOLOGIE ET
PLANIFICATION

39
 PHASE DE PRÉPARATION

2.1 Introduction

La phase de préparation est une étape cruciale pour le succès de tout projet. Elle permet de poser
les bases solides sur lesquelles repose le développement futur. Cette phase inclut l’identification
des acteurs, la spécification des besoins fonctionnels et non fonctionnels, la planification du
projet et le choix des technologies adaptées. Pour le projet de consultation de logs en temps
réel, une bonne préparation est essentielle pour assurer une implémentation fluide et conforme
aux attentes.

2.2 Identification des acteurs

Dans le cadre du système de gestion des logs PS5, plusieurs acteurs ont été identifiés pour
interagir avec les différentes fonctionnalités du système. Ces acteurs et leurs rôles sont décrits
ci-dessous :

- Responsables : Supervisent le système et assurent son bon fonctionnement.

- Service IT : Responsable de la maintenance de l’infrastructure et de la résolution des
problèmes techniques.
- Service Quality : Effectue le contrôle qualité et valide les logs.
- Service Method : Définit et met en œuvre les méthodes de test et de validation.
- Research & Development : Recherche et développe de nouvelles méthodes de test.
- Service Test & Validation : Réalise les tests et valide les résultats.
- Service Support Technique : Fournit un support technique pour le système.
- Service Support Informatique : Offre un support informatique aux utilisateurs du
système.

2.3 Spécification des besoins

Dans cette section, nous détaillons les besoins fonctionnels et non fonctionnels du système de
gestion des logs PS5.

2.3.1 Les besoins fonctionnels

Les besoins fonctionnels décrivent les fonctionnalités que le système doit fournir pour répondre
aux attentes des utilisateurs. Ces besoins incluent :

- Authentification des utilisateurs : Le système doit permettre une authentification

sécurisée par identifiant et mot de passe.
- Consultation des logs : Les utilisateurs doivent pouvoir rechercher et afficher les logs
par différents critères (date, SN, poste, testeur, etc.).
- Téléchargement des logs : Les utilisateurs doivent avoir la possibilité de télécharger
les logs au format souhaité.
- Monitoring en temps réel : Le système doit surveiller les logs en temps réel et les
insérer dans la base de données après vérification.

Spécification des besoins Page 40

 PHASE DE PRÉPARATION

- Gestion des versions : Le système doit permettre le suivi et la vérification des versions
des logiciels installés.
- Diagnostic des erreurs : Les erreurs détectées doivent être enregistrées et accessibles
pour analyse.

2.3.2 Les besoins non fonctionnels

Les besoins non fonctionnels définissent les contraintes et les caractéristiques de performance
du système. Ces besoins incluent :

- Performance : Le système doit être capable de gérer simultanément les requêtes de 70

postes dédiés sans ralentissement.
- Sécurité : Les données doivent être protégées contre tout accès non autorisé.
- Fiabilité : Le système doit garantir une disponibilité de 99,9% pour éviter toute inter-
ruption des opérations.
- Compatibilité : Le système doit être compatible avec Windows Server 2016 et les postes
de production.
- Scalabilité : Le système doit pouvoir évoluer pour prendre en charge un plus grand
nombre de postes si nécessaire.
- Facilité d’utilisation : L’interface web doit être intuitive et facile à utiliser pour les
opérateurs.

2.4 Backlog du produit et la planification

Le backlog du produit est organisé en quatre sprints pour assurer une livraison progressive et
structurée des fonctionnalités du système de gestion des logs PS5. Le tableau ci-dessous détaille
les fonctionnalités, les acteurs impliqués, les user stories associées, et leur priorité.

Id Acteur Fonctionnalité N° sprint User Story Priorité

1 Administrateurs Authentification 1 En tant qu’administrateur, Haute
je souhaite m’authentifier
pour accéder aux données
de manière sécurisée.
2 Service IT IfritConnectTest 4 En tant que membre du Ser- Moyenne
(Vérification des vice IT, je souhaite vérifier
connexions) les connexions pour m’as-
surer de la disponibilité du
système.
3 Administrateurs Version MAPPS 4 En tant qu’administrateur, Moyenne
(Suivi des ver- je souhaite suivre les ver-
sions) sions des logiciels pour ga-
rantir leur mise à jour cor-
recte.

Backlog du produit et la planification Page 41

 PHASE DE PRÉPARATION

4 Service IT Check Version 4 En tant que membre du Ser- Moyenne

(Vérification vice IT, je souhaite vérifier
des versions la version des logiciels ins-
installées) tallés sur chaque poste.
5 Service Quality Log Bord-Diag 2 En tant que membre du Haute
(Diagnostic des Service Qualité, je souhaite
erreurs) consulter les logs de diag-
nostic pour identifier les er-
reurs.
6 Service Quality QualityCheck2 3 En tant que membre du Ser- Moyenne
(Contrôle qua- vice Qualité, je souhaite ef-
lité) fectuer des vérifications de
qualité sur les tests effec-
tués.
7 Service Test & Testeur Au- 3 En tant que membre du Ser- Moyenne
Validation tomatique vice Test, je souhaite gé-
(Gestion des rer les tests automatiques
tests) pour améliorer la producti-
vité des tests.
8 Service Test & Dummy Test 3 En tant que membre du Ser- Moyenne
Validation (Simulation des vice Test, je souhaite simu-
tests) ler des tests pour valider dif-
férents scénarios.
9 Service Quality Chauffe MCB 2 En tant que membre du Moyenne
(Logs de Service Qualité, je souhaite
chauffe) consulter les logs de chauffe
pour analyser les perfor-
mances des tests de chauf-
fage.
10 Service Quality EMC LOG 2 En tant que membre du Ser- Moyenne
(Conformité vice Qualité, je souhaite vé-
électromagné- rifier la conformité électro-
tique) magnétique des cartes.
11 Service Support Support Tech- 2 En tant que membre du sup- Haute
Informatique nique (Assis- port, je souhaite fournir une
tance) assistance technique en cas
d’erreur lors de l’accès aux
logs.

Table 2.1 – Backlog du produit

Backlog du produit et la planification Page 42

 PHASE DE PRÉPARATION

2.5 Planification des Sprints

La planification des sprints permet de définir les objectifs spécifiques de chaque sprint et d’es-
timer le temps nécessaire pour leur réalisation. Le tableau ci-dessous présente la planification
des quatre sprints pour le système de gestion des logs PS5.

Numéro Sprint Objectifs Estimations (Durée)

Sprint 1 2 semaines
- Développement de l’interface de
connexion avec authentification sécuri-
sée (utilisateur et mot de passe).
- Implémentation de la vérification des
rôles et permissions.
- Gestion des accès pour les différents ac-
teurs du système.

Sprint 2 3 semaines
- Implémentation de la fonctionnalité
Log Bord-Diag pour consulter les er-
reurs des tests.
- Implémentation de la fonctionnalité
Chauffe MCB pour la gestion des
logs de température des cartes mères.
- Ajout de la fonctionnalité EMC LOG
pour la vérification de la conformité
électromagnétique.
- Ajout de la possibilité de filtrer par
date, SN (numéro de série), et poste de
test.

Sprint 3 3 semaines
- Ajout de la fonctionnalité Testeur
Automatique pour automatiser les
tests.
- Développement de la fonctionnalité
Dummy Test pour simuler des scéna-
rios de test.
- Intégration de la vérification de la qua-
lité des tests avec la fonctionnalité
QualityCheck2.
- Ajout de la fonction de téléchargement
des logs.

Planification des Sprints Page 43

 PHASE DE PRÉPARATION

Sprint 4 2 semaines
- Ajout de la fonctionnalité Version
MAPPS pour le suivi des versions des
logiciels.
- Vérification des versions des logiciels
installés avec Check Version.
- Vérification des connexions réseau avec
IfritConnectTest.
- Optimisation des performances pour
prendre en charge 70 postes connectés.
- Tests finaux et préparation du déploie-
ment.

Table 2.2 – Planification des Sprints du projet de gestion des logs PS5

Description du diagramme

Le diagramme des cas d’utilisation global met en évidence les éléments suivants :
- Acteurs principaux :
◦ Administrateurs : Gèrent les configurations du système, les accès utilisateurs et
les logs.
◦ Service IT : Responsable de la maintenance technique et de la vérification des
connexions.
◦ Service Quality : Effectue le contrôle qualité et valide les logs.
◦ Service Test & Validation : Réalise les tests et valide les résultats.
- Cas d’utilisation principaux :
◦ Authentification des utilisateurs.
◦ Consultation des logs par critères (date, SN, poste, testeur, etc.).
◦ Téléchargement des logs.
◦ Diagnostic des erreurs (Log Bord-Diag).
◦ Gestion des tests (Testeur Automatique et Dummy Test).
◦ Contrôle qualité (QualityCheck2 ).
◦ Suivi des versions (Version MAPPS et Check Version).
◦ Vérification des connexions (IfritConnectTest).

Utilité du diagramme

Le diagramme des cas d’utilisation global est utilisé pour :

- Identifier les interactions entre les acteurs et le système.
- Définir les fonctionnalités principales à implémenter.
- Servir de base pour la planification des sprints et la priorisation des tâches.
- Communiquer efficacement les besoins fonctionnels aux parties prenantes.

Planification des Sprints Page 44

 PHASE DE PRÉPARATION

2.6 Gestion de projet avec Jira

La gestion du projet a été réalisée avec l’outil Jira pour assurer un suivi rigoureux des tâches
et des sprints.

2.6.1 Vue d’ensemble du projet

Figure 2.1 – Jira - Vue d’ensemble des tâches du projet

Gestion de projet avec Jira Page 45

 PHASE DE PRÉPARATION

2.6.2 Suivi des tâches

Figure 2.2 – Jira - Suivi des tâches complétées

2.6.3 Ticket 1 - Configuration initiale

Figure 2.3 – Jira - Ticket 1 : Configuration initiale du projet

Gestion de projet avec Jira Page 46

 PHASE DE PRÉPARATION

2.6.4 Ticket 2 - Développement backend

Figure 2.4 – Jira - Ticket 2 : Développement du backend

2.6.5 Ticket 3 - Interface utilisateur

Figure 2.5 – Jira - Ticket 3 : Développement de l’interface utilisateur

Gestion de projet avec Jira Page 47

 PHASE DE PRÉPARATION

2.6.6 Ticket 4 - Tests et validation

Figure 2.6 – Jira - Ticket 4 : Tests et validation

Gestion de projet avec Jira Page 48

 PHASE DE PRÉPARATION

2.6.7 Ticket 5 - Déploiement

Figure 2.7 – Jira - Ticket 5 : Déploiement et mise en production

2.6.8 Ticket - Code Python

Figure 2.8 – Jira - Ticket : Développement du code Python

Gestion de projet avec Jira Page 49

 PHASE DE PRÉPARATION

2.6.9 Ticket - Base de données

Figure 2.9 – Jira - Ticket : Configuration de la base de données

2.6.10 Ticket - Intégration Python/DB

Figure 2.10 – Jira - Ticket : Intégration Python et base de données

Gestion de projet avec Jira Page 50

 PHASE DE PRÉPARATION

2.6.11 Ticket - Site web

Figure 2.11 – Jira - Ticket : Développement du site web

2.6.12 Ticket - Hébergement web

Figure 2.12 – Jira - Ticket : Configuration de l’hébergement web

Gestion de projet avec Jira Page 51

 PHASE DE PRÉPARATION

2.6.13 Tests de base de données

Figure 2.13 – Jira - Tests de la base de données

La recherche par numéro de série (SN) permet une identification rapide des logs associés à un
équipement spécifique.

Figure 2.14 – Interface de recherche spécialisée par numéro de série (SN)

2.6.14 Processus de consultation des logs

Le processus de consultation des logs suit un workflow structuré, de la sélection des critères
jusqu’à l’affichage des résultats.

Gestion de projet avec Jira Page 52

 PHASE DE PRÉPARATION

Figure 2.15 – Workflow complet du processus de consultation des logs

2.6.15 Vérification des connexions réseau

La fonctionnalité de vérification des connexions réseau permet au Service IT de s’assurer de la

disponibilité et de la stabilité des connexions.

Figure 2.16 – Interface de vérification des connexions réseau et diagnostic

Gestion de projet avec Jira Page 53

 PHASE DE PRÉPARATION

2.7 Technologies et outils de développement

Dans le cadre du développement du système de gestion des logs PS5, plusieurs technologies et
outils ont été utilisés pour répondre aux besoins fonctionnels et non fonctionnels du projet. Ces
choix technologiques ont été faits en tenant compte des exigences de performance, de sécurité,
de compatibilité et de facilité d’utilisation.

2.7.1 Technologies utilisées

- Base de données MySQL Server : MySQL Server[?] a été choisi pour la gestion des
données en raison de sa robustesse, de sa scalabilité et de sa compatibilité avec les sys-
tèmes Windows Server. La version utilisée est mysql-installer-community-8.0.21.0,
qui offre des fonctionnalités avancées pour la gestion des bases de données relationnelles.

Figure 2.17 – MySQL Server - Système de gestion de base de données relationnelle

- Langage de programmation Python : Python[?] a été utilisé pour le développement

des scripts de reporting et d’insertion des logs. Ce langage a été choisi pour sa simplicité, sa
rapidité de développement et sa large communauté. Les scripts Python ont été convertis en
fichiers exécutables (.exe) pour un lancement automatique sur les postes de production.

Figure 2.18 – Python - Langage de programmation pour les scripts de reporting

- Node.js : Node.js[?] a été utilisé pour le développement de l’application web côté ser-
veur. Grâce à sa capacité à gérer des requêtes en temps réel et à son architecture non
bloquante, Node.js est idéal pour les applications nécessitant une haute performance et
une scalabilité. Express.js, un framework basé sur Node.js, a été utilisé pour simplifier la
gestion des routes et des API.

Figure 2.19 – Node.js - Plateforme de développement pour applications web temps réel

Technologies et outils de développement Page 54

 PHASE DE PRÉPARATION

- Serveur web : IIS (Internet Information Services) IIS[?] a été choisi comme serveur
web pour héberger l’application en raison de sa compatibilité avec Windows Server 2016
et de ses performances élevées pour les applications web.

Figure 2.20 – IIS - Serveur web Microsoft pour l’hébergement d’applications

- Système d’exploitation : Windows Server 2016 Le système d’exploitation Windows

Server 2016[?] a été utilisé pour héberger le serveur web et la base de données, offrant
une plateforme stable et sécurisée pour le déploiement du système.

Figure 2.21 – Windows Server 2016 - Plateforme serveur Microsoft

2.7.2 Outils de développement

- Environnement de développement Visual Studio Code : Visual Studio Code[?] a

été utilisé comme IDE principal pour le développement des scripts Python et des fichiers
Node.js. Cet outil offre une grande flexibilité et de nombreuses extensions pour améliorer
la productivité.

Figure 2.22 – Visual Studio Code - Environnement de développement intégré

Technologies et outils de développement Page 55

 PHASE DE PRÉPARATION

- Outils de conversion Python en .exe PyInstaller : PyInstaller[?] a été utilisé pour

convertir les scripts Python en fichiers exécutables (.exe), permettant leur exécution
automatique sur les postes de production.
- Navigateurs web Les navigateurs web (Google Chrome, Mozilla Firefox, etc.) ont été
utilisés pour tester et valider l’interface utilisateur de l’application web.

Avantages des choix technologiques

Les technologies et outils sélectionnés offrent plusieurs avantages :

- Une compatibilité optimale avec les systèmes existants (Windows Server 2016).
- Une facilité de développement et de maintenance grâce à des outils modernes et perfor-
mants.
- Une scalabilité pour gérer un grand volume de données provenant de 70 postes de pro-
duction.
- Une sécurité renforcée pour protéger les données sensibles des logs.

2.8 Conclusion

Cette phase de préparation a permis de poser les fondations nécessaires pour le développement
du système de consultation de logs en temps réel. Les rôles des acteurs ont été définis, les besoins
ont été spécifiés, la planification a été établie et les choix technologiques ont été justifiés. Cette
base solide permettra de passer à la phase de réalisation avec une vision claire des objectifs à
atteindre.

Conclusion Page 56
Chapitre 3

ARCHITECTURE GÉNÉRALE DU
SYSTÈME

3.1 Introduction

Ce chapitre présente l’architecture générale du système de gestion des logs PS5. Avant de
détailler chaque sprint, il est important de comprendre la structure globale du système, ses
composants principaux et les choix d’architecture qui ont guidé le développement. Cette vue
d’ensemble permettra de mieux comprendre comment chaque sprint contribue à l’ensemble.

3.2 Architecture 2-tiers

Le système repose sur une architecture 2-tiers qui sépare clairement la logique métier de la
présentation :

Tier 1 - Base de données : MySQL centralise toutes les données de logs et assure la persis-
tance des informations.

Tier 2 - Application : Node.js gère la logique métier et l’interface utilisateur, tandis que
Python automatise la collecte des données.

3.3 Architecture technique détaillée

3.3.1 Composants principaux

Le système se compose de plusieurs modules interconnectés :

- Module d’authentification : Gère les accès utilisateurs et les permissions

- Module de consultation : Permet la recherche et l’affichage des logs
- Module de diagnostic : Analyse les erreurs et génère des rapports
- Module d’automatisation : Exécute les tests automatiques
- Module de gestion des versions : Suit les mises à jour logicielles

57
 PHASE DE PRÉPARATION

3.3.2 Technologies utilisées

- Backend : Node.js avec Express.js

- Base de données : MySQL 8.0
- Automatisation : Python 3.8+
- Frontend : HTML5, CSS3, JavaScript
- Serveur web : IIS sur Windows Server 2016

3.3.3 Interface IfritConnectTest

L’interface IfritConnectTest permet de vérifier les connexions réseau et de diagnostiquer les

problèmes de connectivité.

Figure 3.1 – Interface IfritConnectTest pour la vérification des connexions réseau

3.4 Gestion des versions et applications

3.4.1 Suivi des versions Sony Applications

Le système permet de suivre les versions des applications Sony installées sur les différents postes.

Gestion des versions et applications Page 58

 PHASE DE PRÉPARATION

Figure 3.2 – Interface de suivi des versions des applications Sony

Figure 3.3 – Suivi des versions au démarrage des postes de travail

3.5 Gestion des stocks et maintenance

3.5.1 Suivi des stocks de cartes mères PS5

Le système intègre une fonctionnalité de gestion des stocks permettant de suivre l’inventaire
des cartes mères PS5.

Gestion des stocks et maintenance Page 59

 PHASE DE PRÉPARATION

Figure 3.4 – Interface de suivi des stocks de cartes mères PS5 - Vue 1

Figure 3.5 – Interface de suivi des stocks de cartes mères PS5 - Vue 2

3.5.2 Maintenance préventive des câbles testeurs

Le système permet de gérer la maintenance préventive des câbles testeurs SONY, essentielle
pour garantir la qualité des tests.

Gestion des stocks et maintenance Page 60

 PHASE DE PRÉPARATION

Figure 3.6 – Interface de suivi de maintenance préventive - Câbles testeurs SONY

Figure 3.7 – Planification de maintenance préventive - Vue détaillée

Gestion des stocks et maintenance Page 61

 PHASE DE PRÉPARATION

Figure 3.8 – Suivi des interventions de maintenance préventive

3.6 Historique et traçabilité

3.6.1 Historique des cartes mères

Le système maintient un historique complet des cartes mères, permettant de tracer leur utili-
sation et leur maintenance.

Historique et traçabilité Page 62

 PHASE DE PRÉPARATION

Figure 3.9 – Historique des cartes mères - Vue générale

Figure 3.10 – Historique des cartes mères - Détails des interventions

Historique et traçabilité Page 63

 PHASE DE PRÉPARATION

Figure 3.11 – Historique des cartes mères - Suivi des modifications

Figure 3.12 – Historique des cartes mères - Statistiques d’utilisation

3.6.2 Historique des consoles PS5

Le système maintient également un historique détaillé des consoles PS5, incluant les tests
effectués et les interventions réalisées.

Historique et traçabilité Page 64

 PHASE DE PRÉPARATION

Figure 3.13 – Historique des consoles PS5 - Vue générale

Figure 3.14 – Historique des consoles PS5 - Détails des tests

Historique et traçabilité Page 65

 PHASE DE PRÉPARATION

Figure 3.15 – Historique des consoles PS5 - Interventions et maintenance

3.7 Performance et résultats obtenus

3.7.1 Capacité de traitement

Le système a démontré sa capacité à gérer simultanément les requêtes de 70 postes de production

sans ralentissement notable. Les tests de charge ont confirmé la robustesse de l’architecture mise
en place.

3.7.2 Temps de réponse

Les temps de réponse moyens observés sont :

- Authentification : < 2 secondes
- Recherche de logs : < 3 secondes
- Affichage des résultats : < 1 seconde
- Téléchargement de fichiers : < 5 secondes selon la taille

3.7.3 Disponibilité du système

Le système a atteint une disponibilité de 99,9% comme prévu dans les spécifications, avec des
temps de maintenance planifiés minimaux.

Performance et résultats obtenus Page 66

 PHASE DE PRÉPARATION

3.8 Conclusion

Les résultats obtenus démontrent la réussite du projet de développement du système de gestion

des logs PS5. Toutes les fonctionnalités prévues ont été implémentées avec succès, et les perfor-
mances observées répondent aux exigences définies. Le système offre une interface utilisateur
intuitive, des fonctionnalités de recherche avancées, et une gestion complète des données de
production. La traçabilité et l’historique des équipements constituent des atouts majeurs pour
la maintenance et l’optimisation des processus de production.

Conclusion Page 67
Chapitre 4

SPRINT 1 : AUTHENTIFICATION
ET CONSULTATION DES LOGS

68
 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.1 Introduction du Sprint 1

Ce premier sprint marque le début concret de notre aventure de développement. Après avoir
défini la méthodologie et l’architecture générale, il était temps de passer à l’action. Le Sprint
1 se concentre sur les fondations du système : l’authentification sécurisée et les premières fonc-
tionnalités de consultation des logs.

L’objectif principal était de créer un système d’accès sécurisé qui permettrait aux différentes
équipes (Méthode, Qualité, Production) d’accéder aux logs selon leurs permissions respectives.
C’était aussi l’occasion de valider notre architecture technique et de m’assurer que les choix
technologiques étaient les bons.

4.2 Backlog du Sprint 1

Le tableau ci-dessous présente le backlog détaillé du Sprint 1, avec les user stories prioritaires
et les critères d’acceptation :

ID Thème User Story Priorité

1 Authentification En tant qu’utilisateur, je peux m’authentifier Haute
avec un nom d’utilisateur et un mot de passe
pour accéder au système de manière sécuri-
sée.
2 Gestion des rôles En tant qu’administrateur, je peux définir Haute
différents niveaux d’accès selon le rôle de
l’utilisateur (Méthode, Qualité, Production).
3 Consultation des En tant qu’utilisateur authentifié, je peux Haute
logs consulter les logs selon des critères de base
(date, poste, type de test).
4 Interface utilisa- En tant qu’utilisateur, je peux naviguer dans Moyenne
teur une interface intuitive et responsive pour ac-
céder aux fonctionnalités.

Table 4.1 – Backlog du Sprint 1

Backlog du Sprint 1 Page 69

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.3 Conception UML du Sprint 1

4.3.1 Diagramme des cas d’utilisation du Sprint 1

Ce diagramme présente les cas d’utilisation spécifiques au Sprint 1, centrés sur l’authentification
et la consultation de base des logs.

Figure 4.1 – Diagramme des cas d’utilisation du Sprint 1

4.3.2 Diagramme de séquence - Authentification

Ce diagramme illustre le processus d’authentification et de vérification des rôles.

Conception UML du Sprint 1 Page 70

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Figure 4.2 – Diagramme de séquence - Processus d’authentification

Conception UML du Sprint 1 Page 71

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Figure 4.3 – Sprint 1 - Authentification et base de données

Figure 4.4 – Sprint 2 - Interface web et consultation

Figure 4.5 – Backlogs des sprints 1 et 2 - Planification des fonctionnalités

Conception UML du Sprint 1 Page 72

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Figure 4.6 – Sprint 3 - Tests et automatisation

Figure 4.7 – Sprint 4 - Finalisation et déploiement

Figure 4.8 – Backlogs des sprints 3 et 4 - Finalisation du projet

4.3.3 Diagramme de séquence - Consultation des logs

Ce diagramme illustre le processus de consultation des logs par les utilisateurs authentifiés.

Conception UML du Sprint 1 Page 73

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Figure 4.9 – Diagramme de séquence - Consultation des logs

4.3.4 Interface utilisateur - Accès général

Ce diagramme présente l’interface générale d’accès utilisateur avec les différentes fonctionnalités
disponibles.

Figure 4.10 – Interface utilisateur - Accès général au système

Conception UML du Sprint 1 Page 74

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.4 Description textuelle des cas d’utilisation

4.4.1 Cas d’utilisation : S’authentifier

Nom du cas d’utili- S’authentifier

sation
Acteur Utilisateur (tous les rôles)
Résumé L’utilisateur s’authentifie pour accéder au système de consul-
tation des logs.
Pré-condition L’utilisateur dispose d’un compte valide dans le système.
Scénario nominal 1. L’utilisateur accède à la page de connexion.
2. L’utilisateur saisit son nom d’utilisateur et son mot de
passe.
3. Le système vérifie les identifiants.
4. Le système détermine le rôle de l’utilisateur.
5. Le système redirige vers l’interface appropriée.
Enchaînements al- Si les identifiants sont incorrects, le système affiche un message
ternatifs d’erreur.
Si le compte est désactivé, le système informe l’utilisateur.
Post conditions L’utilisateur est authentifié et accède à l’interface correspon-
dant à son rôle.

Table 4.2 – Description du cas d’utilisation "S’authentifier"

4.4.2 Cas d’utilisation : Consulter les logs

Nom du cas d’utili- Consulter les logs

sation
Acteur Utilisateur authentifié
Résumé L’utilisateur consulte les logs selon des critères de base.
Pré-condition L’utilisateur doit être authentifié.
Scénario nominal 1. L’utilisateur accède à l’interface de consultation.
2. L’utilisateur sélectionne les critères de recherche (date,
poste, type).
3. Le système interroge la base de données.
4. Le système affiche les résultats filtrés.
Enchaînements al- Si aucun résultat n’est trouvé, le système affiche un message
ternatifs approprié.
Si l’utilisateur n’a pas les permissions, le système refuse l’ac-
cès.
Post conditions Les logs correspondant aux critères sont affichés à l’utilisateur.

Table 4.3 – Description du cas d’utilisation "Consulter les logs"

Description textuelle des cas d’utilisation Page 75

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.5 Réalisation du Sprint 1

4.5.1 Interface d’authentification

L’interface d’authentification a été conçue pour être simple, sécurisée et professionnelle. Voici
les captures d’écran de l’implémentation :

Figure 4.11 – Interface d’authentification principale

Figure 4.12 – Processus d’authentification avec validation

Réalisation du Sprint 1 Page 76

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.5.2 Interface d’accueil

Après authentification réussie, les utilisateurs accèdent à une interface d’accueil personnalisée
selon leur rôle :

Figure 4.13 – Interface d’accueil avec navigation vers les fonctionnalités

4.5.3 Fonctionnalités de consultation de base

Les premières fonctionnalités de consultation des logs ont été implémentées avec des filtres de
base :

Réalisation du Sprint 1 Page 77

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Réalisation du Sprint 1 Page 78

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.5.4 Interface de recherche par critères

L’interface de recherche par critères permet aux utilisateurs de filtrer les logs selon différents
paramètres :

Figure 4.15 – Interface de recherche par critères spécifiques

4.5.5 Affichage des résultats de recherche

L’interface d’affichage des résultats permet de visualiser les logs trouvés selon les critères sélec-
tionnés :

Réalisation du Sprint 1 Page 79

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Figure 4.16 – Interface d’affichage des résultats de recherche

4.5.6 Recherche par numéro de série

L’interface de recherche par numéro de série (SN) permet une identification précise des équipe-
ments :

Figure 4.17 – Interface de recherche par numéro de série

4.5.7 Interface de connexion initiale

L’interface de connexion initiale présente l’écran d’accueil du système :

Réalisation du Sprint 1 Page 80

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

Figure 4.18 – Interface de connexion initiale du système

4.5.8 Interface d’accueil après connexion

L’interface d’accueil présente le tableau de bord principal après authentification réussie :

Figure 4.19 – Interface d’accueil - Tableau de bord principal

4.6 Tests et validation du Sprint 1

4.6.1 Tests d’authentification

J’ai testé plusieurs scénarios d’authentification : - Connexion avec des identifiants valides -
Tentative de connexion avec des identifiants invalides - Test des différents rôles et permissions
- Vérification de la sécurité des sessions

Tests et validation du Sprint 1 Page 81

 SPRINT 1 : AUTHENTIFICATION ET CONSULTATION DES LOGS

4.6.2 Tests de consultation

Les tests de consultation ont validé : - La récupération correcte des logs selon les critères -
Les performances de requête avec différents volumes de données - L’affichage correct selon les
permissions utilisateur - La gestion des cas d’erreur

4.7 Bilan du Sprint 1

Le Sprint 1 s’est terminé avec succès. Les objectifs principaux ont été atteints : - Système d’au-
thentification sécurisé implémenté - Gestion des rôles et permissions fonctionnelle - Interface
de consultation de base opérationnelle - Tests de validation passés avec succès

Les retours des utilisateurs ont été positifs, confirmant que l’approche était la bonne. Le système
était maintenant prêt pour l’ajout de fonctionnalités plus avancées dans le Sprint 2.

Bilan du Sprint 1 Page 82

Chapitre 5

SPRINT 2 : FONCTIONNALITÉS
AVANCÉES

83
 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.1 Introduction du Sprint 2

Le Sprint 2 marque l’évolution de notre système vers des fonctionnalités plus sophistiquées. Fort
du succès du Sprint 1, j’ai pu me concentrer sur l’ajout de capacités avancées que les équipes
de production réclamaient depuis longtemps. Ce sprint se focalise sur trois axes majeurs :
la consultation des erreurs de diagnostic, la vérification de conformité électromagnétique, et
l’amélioration des capacités de recherche.

L’objectif était de transformer notre système de consultation basique en un véritable outil d’aide
à la décision pour les équipes Qualité et Méthode. Les retours du Sprint 1 avaient confirmé que
l’approche était bonne, mais les utilisateurs avaient besoin de fonctionnalités plus spécialisées.

5.2 Backlog du Sprint 2

Le tableau ci-dessous présente le backlog détaillé du Sprint 2, avec les nouvelles fonctionnalités
prioritaires :

ID Thème User Story Priorité

1 Diagnostic des En tant qu’utilisateur, je peux consulter les Haute
erreurs erreurs des tests via la fonctionnalité « Log
Bord-Diag ».
2 Logs de tempé- En tant qu’utilisateur, je peux consulter les Moyenne
rature logs de température des cartes mères via la
fonctionnalité « Chauffe MCB ».
3 Conformité élec- En tant qu’utilisateur, je peux vérifier la Moyenne
tromagnétique conformité électromagnétique des cartes via
la fonctionnalité « EMC LOG ».
4 Recherche avan- En tant qu’utilisateur, je peux filtrer les logs Haute
cée en fonction de critères comme la date, le SN
(numéro de série) et le poste de test.

Table 5.1 – Backlog du Sprint 2

Backlog du Sprint 2 Page 84

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.3 Conception UML du Sprint 2

5.3.1 Diagramme des cas d’utilisation du Sprint 2

Ce diagramme présente les nouveaux cas d’utilisation ajoutés dans le Sprint 2, centrés sur les
fonctionnalités de diagnostic et de conformité.

Figure 5.1 – Diagramme des cas d’utilisation du Sprint 2

Conception UML du Sprint 2 Page 85

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.3.2 Diagramme de séquence - Consultation des erreurs

Ce diagramme illustre le processus de consultation des erreurs de diagnostic.

Figure 5.2 – Diagramme de séquence - Consultation des erreurs

5.3.3 Diagramme de séquence - Vérification EMC

Ce diagramme illustre le processus de vérification de conformité électromagnétique.

Figure 5.3 – Diagramme de séquence - Vérification de conformité électromagnétique

5.3.4 Diagramme de séquence - Suivi des versions

Ce diagramme illustre le processus de suivi et de vérification des versions logicielles.

Conception UML du Sprint 2 Page 86

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.4 – Diagramme de séquence - Suivi des versions logicielles

5.3.5 Diagramme de séquence - Vérification des connexions

Ce diagramme illustre le processus de vérification des connexions réseau et de diagnostic.

Figure 5.5 – Diagramme de séquence - Vérification des connexions réseau

Conception UML du Sprint 2 Page 87

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.4 Description textuelle des cas d’utilisation

5.4.1 Cas d’utilisation : Consulter les erreurs des tests

Nom du cas d’utili- Consulter les erreurs des tests

sation
Acteur Administrateur, Opérateur
Résumé L’utilisateur peut consulter les erreurs des tests via la fonc-
tionnalité « Log Bord-Diag ».
Pré-condition L’utilisateur doit être authentifié et connecté à l’interface de
diagnostic.
Scénario nominal 1. L’utilisateur accède à l’interface de consultation des erreurs.
2. Le système affiche la liste des erreurs disponibles.
3. L’utilisateur sélectionne un log d’erreur pour afficher les
détails.
4. Le système affiche les détails complets de l’erreur sélection-
née.
Enchaînements al- Si aucun log d’erreur n’est disponible, le système affiche un
ternatifs message indiquant qu’aucune erreur n’a été détectée.
Post conditions Les détails des erreurs sont affichés à l’utilisateur.

Table 5.2 – Description du cas d’utilisation "Consulter les erreurs des tests"

Description textuelle des cas d’utilisation Page 88

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.4.2 Cas d’utilisation : Vérifier la conformité électromagnétique

Nom du cas d’utili- Vérifier la conformité électromagnétique

sation
Acteur Administrateur, Opérateur
Résumé L’utilisateur peut vérifier la conformité électromagnétique via
la fonctionnalité « EMC LOG ».
Pré-condition L’utilisateur doit être authentifié.
Scénario nominal 1. L’utilisateur accède à l’interface de conformité électroma-
gnétique.
2. Le système affiche les résultats des tests de conformité.
3. L’utilisateur peut sélectionner un test pour afficher les dé-
tails.
Enchaînements al- Si aucun log de conformité n’est disponible, le système affiche
ternatifs un message d’alerte.
Post conditions Les résultats de la vérification sont affichés à l’utilisateur.

Table 5.3 – Description du cas d’utilisation "Vérifier la conformité électromagnétique"

Description textuelle des cas d’utilisation Page 89

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.5 Réalisation du Sprint 2

5.5.1 Interface Log Bord-Diag

L’interface de diagnostic des erreurs a été développée pour offrir une vue claire et détaillée des
problèmes détectés :

Figure 5.6 – Interface Log Bord-Diag - Consultation des erreurs

5.5.2 Interface EMC LOG

L’interface de vérification de conformité électromagnétique permet aux équipes Qualité de va-

lider les tests EMC :

Réalisation du Sprint 2 Page 90

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.7 – Interface EMC LOG - Vérification de conformité

5.5.3 Stratégies de test fonctionnel

J’ai implémenté des stratégies de test avancées pour valider les nouvelles fonctionnalités :

Réalisation du Sprint 2 Page 91

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.8 – Automatisation des tests

Figure 5.9 – Simulation de scénarios

Figure 5.10 – Stratégies de test fonctionnel du Sprint 2

5.5.4 Tests de performance

Les tests de performance ont validé la robustesse du système avec les nouvelles fonctionnalités :

Réalisation du Sprint 2 Page 92

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.11 – Vérification des connexions

Figure 5.12 – Performance consultation logs

5.5.5 Résultats de recherche avancée

L’interface de résultats de recherche permet d’afficher et de télécharger les logs trouvés :

Réalisation du Sprint 2 Page 93

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.13 – Interface de résultats de recherche avec options de téléchargement

5.5.6 Recherche de logs - Étape 1

Première étape du processus de recherche de logs avec sélection des critères de base :

Réalisation du Sprint 2 Page 94

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.14 – Recherche de logs - Sélection des critères de base

5.5.7 Recherche de logs - Étape 2

Deuxième étape avec affichage des résultats de recherche :

Réalisation du Sprint 2 Page 95

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.15 – Recherche de logs - Affichage des résultats

5.5.8 Recherche de logs - Étape 3

Troisième étape avec détails des logs trouvés :

Réalisation du Sprint 2 Page 96

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.16 – Recherche de logs - Détails des résultats

5.5.9 Recherche de logs - Étape 4

Quatrième étape avec options de filtrage avancées :

Figure 5.17 – Recherche de logs - Filtrage avancé

5.5.10 Recherche par numéro de série - Étape 1

Première étape de recherche par numéro de série :

Réalisation du Sprint 2 Page 97

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.18 – Recherche par numéro de série - Sélection du SN

5.5.11 Recherche par numéro de série - Étape 2

Deuxième étape avec résultats de recherche par SN :

Réalisation du Sprint 2 Page 98

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.19 – Recherche par numéro de série - Résultats

5.5.12 Recherche PS5 par numéro de série - Étape 1

Première étape de recherche spécifique aux PS5 par numéro de série :

Figure 5.20 – Recherche PS5 par numéro de série - Sélection

Réalisation du Sprint 2 Page 99

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

5.5.13 Recherche PS5 par numéro de série - Étape 2

Deuxième étape avec résultats de recherche PS5 par SN :

Figure 5.21 – Recherche PS5 par numéro de série - Résultats

5.5.14 Affichage et téléchargement des logs

Interface permettant l’affichage et le téléchargement des logs trouvés :

Figure 5.22 – Interface d’affichage et téléchargement des logs

5.5.15 Consultation des logs détaillés

Interface de consultation détaillée des logs avec toutes les informations :

Réalisation du Sprint 2 Page 100

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

Figure 5.23 – Interface de consultation détaillée des logs

5.6 Tests et validation du Sprint 2

5.6.1 Tests de diagnostic

Les tests de diagnostic ont validé : - La détection correcte des erreurs de test - L’affichage détaillé
des informations d’erreur - La classification des erreurs par type et gravité - L’historique des
erreurs par équipement

5.6.2 Tests de conformité EMC

Les tests de conformité électromagnétique ont vérifié : - La récupération des données de test
EMC - L’analyse des résultats de conformité - La génération de rapports de conformité - L’alerte
en cas de non-conformité

5.6.3 Tests de recherche avancée

Les tests de recherche avancée ont confirmé : - Le filtrage par numéro de série - La recherche
par date et plage temporelle - Le filtrage par poste de test - Les performances avec de gros
volumes de données

5.7 Bilan du Sprint 2

Le Sprint 2 s’est terminé avec un succès remarquable. Les objectifs principaux ont été atteints : -
Fonctionnalité Log Bord-Diag opérationnelle - Interface EMC LOG fonctionnelle - Recherche
avancée par critères multiples - Tests de performance validés - Retours utilisateurs très positifs

Les équipes Qualité et Méthode ont particulièrement apprécié les nouvelles fonctionnalités de

Bilan du Sprint 2 Page 101

 SPRINT 2 : FONCTIONNALITÉS AVANCÉES

diagnostic et de conformité. Le système commençait à devenir un véritable outil de travail quo-

tidien. Le Sprint 3 pourrait maintenant se concentrer sur l’automatisation et les fonctionnalités
de simulation.

Bilan du Sprint 2 Page 102

Chapitre 6

SPRINT 3 : TESTS ET SIMULATION

103
 SPRINT 3 : TESTS ET SIMULATION

6.1 Introduction du Sprint 3

Le Sprint 3 représente un tournant important dans notre projet. Après avoir mis en place les
fonctionnalités de consultation et de diagnostic, il était temps de passer à l’automatisation et
à la simulation. Ce sprint se concentre sur trois axes majeurs : l’automatisation des tests, la
simulation de scénarios, et l’ajout de fonctionnalités de téléchargement.

L’objectif était de transformer notre système de consultation en un véritable outil d’automa-

tisation pour les équipes de test. Les retours des Sprints précédents avaient montré que les
utilisateurs passaient beaucoup de temps à répéter des tâches manuelles. L’automatisation a
été devenue une priorité.

6.2 Backlog du Sprint 3

ID Thème User Story Priorité

1 Testeur automa- En tant qu’utilisateur, je peux automatiser Haute
tique les tests via la fonctionnalité « Testeur Au-
tomatique ».
2 Simulation de En tant qu’utilisateur, je peux simuler des Moyenne
tests scénarios de test via la fonctionnalité «
Dummy Test ».
3 Contrôle qualité En tant qu’utilisateur, je peux effectuer des Moyenne
vérifications de qualité via la fonctionnalité
« QualityCheck2 ».
4 Téléchargement En tant qu’utilisateur, je peux télécharger les Haute
logs pour analyse externe.

Table 6.1 – Backlog du Sprint 3

Backlog du Sprint 3 Page 104

 SPRINT 3 : TESTS ET SIMULATION

6.3 Conception UML du Sprint 3

6.3.1 Diagramme des cas d’utilisation du Sprint 3

Figure 6.1 – Diagramme des cas d’utilisation du Sprint 3

6.3.2 Diagramme de séquence - Automatisation des tests

Ce diagramme illustre le processus d’automatisation des tests et de génération de rapports.

Figure 6.2 – Diagramme de séquence - Automatisation des tests

Conception UML du Sprint 3 Page 105

 SPRINT 3 : TESTS ET SIMULATION

6.3.3 Diagramme de séquence - Simulation de scénarios

Ce diagramme illustre le processus de simulation de différents scénarios de test.

Figure 6.3 – Diagramme de séquence - Simulation de scénarios

6.4 Description textuelle des cas d’utilisation

6.4.1 Cas d’utilisation : Automatiser les tests

Nom du cas d’utili- Automatiser les tests

sation
Acteur Testeur, Administrateur
Résumé L’utilisateur peut automatiser l’exécution de tests répétitifs.
Pré-condition L’utilisateur doit être authentifié avec les permissions appro-
priées.
Scénario nominal 1. L’utilisateur accède à l’interface d’automatisation.
2. L’utilisateur configure les paramètres de test.
3. Le système exécute les tests automatiquement.
4. Le système génère un rapport de résultats.
Enchaînements al- Si un test échoue, le système arrête la séquence et notifie l’uti-
ternatifs lisateur.
Post conditions Les tests sont exécutés et les résultats sont disponibles.

Table 6.2 – Description du cas d’utilisation "Automatiser les tests"

Description textuelle des cas d’utilisation Page 106

 SPRINT 3 : TESTS ET SIMULATION

6.5 Réalisation du Sprint 3

6.5.1 Interface QualityCheck2

Figure 6.4 – Interface QualityCheck2 pour les testeurs

6.5.2 Interface IfritConnectTest

Figure 6.5 – Interface IfritConnectTest pour la vérification des connexions

6.6 Tests et validation du Sprint 3

6.6.1 Tests d’automatisation

Les tests d’automatisation ont validé : - L’exécution automatique des séquences de test - La
gestion des erreurs pendant l’automatisation - La génération de rapports détaillés - L’intégration
avec les systèmes existants

Tests et validation du Sprint 3 Page 107

 SPRINT 3 : TESTS ET SIMULATION

6.7 Bilan du Sprint 3

Le Sprint 3 s’est terminé avec succès : - Testeur automatique opérationnel - Fonctionnalités

de simulation implémentées - Interface QualityCheck2 fonctionnelle - Téléchargement des logs
disponible - Automatisation des processus de test

L’automatisation a considérablement réduit le temps de test et amélioré la précision des ré-

sultats. Le Sprint 4 pourra maintenant se concentrer sur l’optimisation et la finalisation du
système.

Bilan du Sprint 3 Page 108

Chapitre 7

SPRINT 4 : FINALISATION ET
OPTIMISATION

109
 SPRINT 4 : FINALISATION ET OPTIMISATION

7.1 Introduction du Sprint 4

Le Sprint 4 représente la phase finale de notre projet, le moment où tout doit se rassembler
pour former un système complet et optimisé. Après trois sprints de développement intense, il
était temps de finaliser les fonctionnalités restantes, optimiser les performances, et préparer le
système pour le déploiement en production.

L’objectif principal était de s’assurer que le système pouvait supporter la charge de 70 postes
connectés simultanément, tout en ajoutant les dernières fonctionnalités de gestion des versions
et de vérification des connexions. C’était aussi l’occasion de peaufiner l’expérience utilisateur
et de valider que tout fonctionnait parfaitement ensemble.

7.2 Backlog du Sprint 4

ID Thème User Story Priorité

1 Suivi des ver- En tant qu’utilisateur, je peux suivre les ver- Moyenne
sions sions des logiciels via la fonctionnalité « Ver-
sion MAPPS ».
2 Vérification des En tant qu’utilisateur, je peux vérifier les ver- Moyenne
versions sions des logiciels installés via la fonctionna-
lité « Check Version ».
3 Vérification des En tant qu’utilisateur, je peux vérifier les Moyenne
connexions connexions réseau via la fonctionnalité «
IfritConnectTest ».
4 Optimisation En tant qu’utilisateur, je peux bénéficier Haute
des perfor- d’un système optimisé qui supporte 70 postes
mances connectés en simultané.
5 Déploiement En tant qu’utilisateur, je peux utiliser un sys- Haute
tème testé et déployé avec succès.

Table 7.1 – Backlog du Sprint 4

Backlog du Sprint 4 Page 110

 SPRINT 4 : FINALISATION ET OPTIMISATION

7.3 Conception UML du Sprint 4

7.3.1 Diagramme des cas d’utilisation du Sprint 4

Figure 7.1 – Diagramme des cas d’utilisation du Sprint 4

7.3.2 Diagramme de séquence - Gestion des versions

Ce diagramme illustre le processus de gestion et de suivi des versions logicielles.

Figure 7.2 – Diagramme de séquence - Gestion des versions logicielles

7.4 Description textuelle des cas d’utilisation

7.4.1 Cas d’utilisation : Suivre les versions des logiciels

Description textuelle des cas d’utilisation Page 111

 SPRINT 4 : FINALISATION ET OPTIMISATION

Nom du cas d’utili- Suivre les versions des logiciels

sation
Acteur Utilisateur
Résumé L’utilisateur peut suivre l’état des versions des logiciels ins-
tallés sur chaque poste.
Pré-condition L’utilisateur doit être authentifié et connecté à l’interface de
gestion des versions.
Scénario nominal 1. L’utilisateur accède à l’interface de gestion des versions.
2. Le système affiche la liste des versions des logiciels installés
sur les postes.
3. L’utilisateur peut consulter et filtrer la liste selon les ver-
sions souhaitées.
Enchaînements al- Si une version est obsolète, le système recommande une mise
ternatifs à jour.
Post conditions L’utilisateur visualise les versions des logiciels installés et peut
planifier les mises à jour.

Table 7.2 – Description du cas d’utilisation "Suivre les versions des logiciels"

7.5 Réalisation du Sprint 4

7.5.1 Suivi des versions Sony Applications

Figure 7.3 – Interface de suivi des versions des applications Sony

Réalisation du Sprint 4 Page 112

 SPRINT 4 : FINALISATION ET OPTIMISATION

Figure 7.4 – Suivi des versions au démarrage des postes de travail

7.5.2 Gestion des stocks de cartes mères PS5

Figure 7.5 – Interface de suivi des stocks de cartes mères PS5 - Vue 1

Réalisation du Sprint 4 Page 113

 SPRINT 4 : FINALISATION ET OPTIMISATION

Figure 7.6 – Interface de suivi des stocks de cartes mères PS5 - Vue 2

Réalisation du Sprint 4 Page 114

 SPRINT 4 : FINALISATION ET OPTIMISATION

7.5.3 Maintenance préventive des câbles testeurs

Figure 7.7 – Suivi préventif câbles testeurs SONY

Figure 7.8 – Suivi préventif câbles testeurs SONY 2

Figure 7.9 – Maintenance préventive - Câbles testeurs SONY

Réalisation du Sprint 4 Page 115

 SPRINT 4 : FINALISATION ET OPTIMISATION

7.5.4 Maintenance préventive - Vue supplémentaire

Vue supplémentaire de la maintenance préventive des câbles testeurs :

Figure 7.10 – Maintenance préventive - Vue supplémentaire des câbles testeurs

7.5.5 Historique des cartes mères - Vue 1

Interface de consultation de l’historique des cartes mères :

Réalisation du Sprint 4 Page 116

 SPRINT 4 : FINALISATION ET OPTIMISATION

Figure 7.11 – Historique des cartes mères - Vue générale

7.5.6 Historique des cartes mères - Vue 2

Détails de l’historique des cartes mères :

Figure 7.12 – Historique des cartes mères - Détails

7.5.7 Historique des cartes mères - Vue 3

Vue détaillée de l’historique des cartes mères :

Réalisation du Sprint 4 Page 117

 SPRINT 4 : FINALISATION ET OPTIMISATION

Figure 7.13 – Historique des cartes mères - Vue détaillée

7.5.8 Historique des cartes mères - Vue 4

Vue complète de l’historique des cartes mères :

Figure 7.14 – Historique des cartes mères - Vue complète

7.5.9 Historique des consoles PS5 - Vue 1

Interface de consultation de l’historique des consoles PS5 :

Réalisation du Sprint 4 Page 118

 SPRINT 4 : FINALISATION ET OPTIMISATION

Figure 7.15 – Historique des consoles PS5 - Vue générale

7.5.10 Historique des consoles PS5 - Vue 2

Détails de l’historique des consoles PS5 :

Figure 7.16 – Historique des consoles PS5 - Détails

7.5.11 Historique des consoles PS5 - Vue 3

Vue complète de l’historique des consoles PS5 :

Réalisation du Sprint 4 Page 119

 SPRINT 4 : FINALISATION ET OPTIMISATION

Figure 7.17 – Historique des consoles PS5 - Vue complète

7.6 Tests et validation du Sprint 4

7.6.1 Tests de performance

Les tests de performance ont validé : - Support de 70 postes connectés simultanément - Temps
de réponse inférieur à 2 secondes - Gestion efficace de la mémoire et des ressources - Stabilité
du système sur de longues périodes

7.6.2 Tests de charge

Les tests de charge ont confirmé : - Capacité de traitement de 1000+ requêtes par minute -
Gestion optimale des connexions simultanées - Pas de dégradation des performances sous charge
- Récupération automatique après pic de charge

7.7 Bilan du Sprint 4

Le Sprint 4 s’est terminé avec un succès complet : - Suivi des versions opérationnel - Gestion des
stocks implémentée - Maintenance préventive fonctionnelle - Optimisation des performances
validée - Système prêt pour le déploiement en production

Bilan du Sprint 4 Page 120

 SPRINT 4 : FINALISATION ET OPTIMISATION

Le système est maintenant complet, optimisé et prêt à être utilisé par les équipes de production.
Tous les objectifs initiaux ont été atteints et même dépassés.

Bilan du Sprint 4 Page 121

Chapitre 8

Conclusion Générale

Ce projet de fin d’études a représenté bien plus qu’un simple exercice académique. Il s’agit d’un
véritable défi professionnel où chaque étape – de la conception à la réalisation – a mobilisé une
panoplie de compétences techniques, organisationnelles et humaines.

L’automatisation de la gestion des logs dans un environnement de production comme celui de

MPSI n’est pas seulement une amélioration technique. C’est un saut stratégique vers l’efficacité,
la traçabilité et la réactivité en temps réel.

Grâce à ce projet :

- Le temps d’analyse des pannes a été réduit de façon significative.

- La productivité des équipes techniques a été optimisée.
- La visualisation centralisée des données a permis une meilleure prise de décision.
- Le système mis en place est évolutif, personnalisable et sécurisé.
Ce travail a démontré que même dans des environnements industriels complexes, l’innovation
numérique peut générer un retour sur investissement concret et un gain de temps me-
surable. Il ouvre la voie à une modernisation progressive des outils de suivi et à une meilleure
gouvernance de la donnée.

Enfin, au-delà des bénéfices techniques, ce projet illustre la capacité d’un étudiant à gérer un
cycle de développement complet, à dialoguer avec différents intervenants, et à livrer une solution
robuste et fonctionnelle.

122