feat: add final opening

chapters/final-opening.typ

@@ -1,4 +1,11 @@
 #pagebreak(weak: true)
 == Ouverture
 
-Content
+Au cours des trois années d'alternance passées au sein de l'entreprise Unit Solution, j'ai activement pu participer au développement et à la maintenance du projet InfSuite. Comme pour l'année dernière, j'ai apporté des améliorations à l'outil d'administration. Toujours orienté sur la gestion de la base de données, j'ai pu créer une fonctionnalité pour vérifier les scripts exécutés précédemment sur la base de données. Comme expliqué plus tôt dans ce document, InfSuite utilise des scripts SQL pour permettre de mettre à jour les schéma de base de données et ainsi éviter des modifications manuelles en base de données. Pour garder une liste des scripts déjà exécutés sur le serveur, un écran dans l'application permet de voir rapidement l'historique d'exécution des scripts.
+
+Ajouter ce genre de gestion de base de données dans l'application permet également de remettre en question la manière actuelle de faire les choses pour tenter d'améliorer le processus.\
+Actuellement, pour gérer les schémas de base de données, nous utilisons le logiciel Power Designer. Il permet de gérer les définitions des modèles de données avec les relations, les définitions de clés primaires, etc. Il ne permet cependant que de générer des définitions, il ne permet pas d'effectuer les actions sur la base de données, il reste totalement hors connexion.\
+Une fois les modifications effectuées dans l'outil, il génère le nouveau schéma de base avec les définitions de tables, colonnes,... Pour créer les scripts qui vont mettre à jour la base de données avec ces nouvelles définitions, il faut aller chercher dans le fichier de schéma de base de données, modifié par Power Designer, les différentes modifications. On peut alors créer un nouveau fichier ``` .sql``` dans lequel on va y ajouter les instructions SQL permettant d'effectuer ces modifications. Une fois le script rédigé, on peut tester que tout fonctionne correctement sur une base de développement. Si tout fonctionne comme prévu, alors il faut le dupliquer dans les dossiers de configuration spécifiques à chaque environnement et pousser toutes ces modifications sur Azure Devops.
+
+Toute cette gestion complexifie la simple de tâche de mettre à jour les informations en base de données. Il serait plus convenant de trouver une alternative moins complexe pour effectuer cette tâche. Après avoir mis à jour la base de données, on peut alors légitimement se poser la question :Comment simplifier l'administration d'une base de données.\
+On pourrait alors partir par exemple sur une implémentation dans l'outil d'administration du projet pour effectuer cette tâche longue et récurrente.

chapters/réalisation.typ

@@ -220,7 +220,7 @@ Pour gérer l'inférence des données, je dois rajouter une nouvelle étape de v
 JsonTokenType.String when reader.TryGetDateTime(out DateTime datetime) => DateTime.SpecifyKind(datetime, DateTimeKind.Unspecified),
 ```
 
-Pour préciser quels sont les entitées en base de données qui n'utilisent pas le format par défaut DateTime2, je rajoute à la variable ``` Version``` dans les entitées concernées l'anotation ``` [JsonConverter(typeof(DateTimeUtcConverter))]```. De la sorte je le force à utiliser un convertisseur différents.
+Pour préciser quels sont les entitées en base de données qui n'utilisent pas le format par défaut DateTime2, je rajoute à la variable ``` Version``` dans les entitées concernées l'anotation ``` [JsonConverter(typeof(DateTimeUtcConverter))]```. De la sorte ,je le force à utiliser un convertisseur différent.
 
 Pour permettre de gérer ces dates différement j'ai pu créer deux convertisseurs de dates. Ils ont un fonctionnement similaire, il ne varient que par le type de date retourné. Dans le bloc de code @codebloc-dt-unspecified les dates sont retournée sans fuseau horaire s'il n'est pas présent tandis que dans le bloc de code @codebloc-dt-utc il prends en valeur par défaut le fuseau horaire UTC.\
 Il est bon de remarquer que j'utilise dans mon anotation de variable pour mon entité ci-avant, le convertisseur que j'expose dans le bloc de code @codebloc-dt-utc.
@@ -229,11 +229,11 @@ Il est bon de remarquer que j'utilise dans mon anotation de variable pour mon en
 
 #figure(image("../assets/images/codebloc-dt-utc.png"), caption: [Bloc de code d'un convertisseur de date avec fuseau horaire])<codebloc-dt-utc>
 
-Pour m'assurer que mes changements sont corrects et que je n'ajoute pas de code qui pourrait mettre en défaut l'application, je créé pour toute l'application des tests qui permettent de vérifier que la conversion fonctionne comme attendu. J'ai rajouté des tests manquants, avec le test d'inférence des types comme dans le bloc de code @codebloc-dt-test-infer, pour vérifier qu'en fonction du continu le convertisseur JSON retrouve le bon type de données. J'ai également ajouté des tests pour les deux types de convertisseurs de données en lui fournissant différentes formes de dates et en m'assurant que ce qu'il me retourne, correspond à une date bien formée avec ou sans fuseau horaire en fonction du contexte.
+Pour m'assurer que mes changements sont corrects et que je n'ajoute pas de code qui pourrait mettre en défaut l'application, je créais pour toute l'application des tests qui permettent de vérifier que la conversion fonctionne comme attendu. J'ai rajouté des tests manquants, avec le test d'inférence des types comme dans le bloc de code @codebloc-dt-test-infer, pour vérifier qu'en fonction du continu le convertisseur JSON retrouve le bon type de données. J'ai également ajouté des tests pour les deux types de convertisseurs de données en lui fournissant différentes formes de dates et en m'assurant que ce qu'il me retourne, correspond à une date bien formée avec ou sans fuseau horaire en fonction du contexte.
 
 #figure(image("../assets/images/codebloc-dt-test-infer.png"), caption: [Bloc de code d'un test d'inférence JSON])<codebloc-dt-test-infer>
 
-Mes derniers ajouts portent sur des modifications mineures comme des changements dans les logs de l'application pour facilier le déboguage, des ajout de type de date dans les différentes énumérations concernées, etc.\
+Mes derniers ajouts portent sur des modifications mineures comme des changements dans les logs de l'application pour faciliter le débogage, des ajouts de type de date dans les différentes énumérations concernées, etc.\
 
 #pagebreak(weak: true)
 == Résultats
@@ -262,7 +262,7 @@ Une fois le serveur de production mis à jour avec les nouveaux éléments, j'ef
   )
 )<result_sheet_benchmark_2>
 
-Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas forcement de gros indices sur la différences par rapport à la première analyse comportant potentiellement un biais. Je constate une inversion sur la quantité de données traitées, cette fois-ci la nouvelle base de données à eu plus d'OIs à traiter et par conséquent les temps de traitement on aussi augmentés. Une comparaison avancée me permet d'obtenir un comparatif plus explicite entre les deux base. 
+Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas forcément de gros indices sur les différences par rapport à la première analyse comportant potentiellement un biais. Je constate une inversion sur la quantité de données traitées, cette fois-ci la nouvelle base de données à eu plus d'OIs à traiter et par conséquent les temps de traitements ont aussi augmenté. Une comparaison avancée me permet d'obtenir un comparatif plus explicite entre les deux bases. 
 
 #figure(
   table(
@@ -280,6 +280,6 @@ Le projet bénéficie donc des améliorations de performances promises par l'éq
 
 === Problèmes rencontrés
 
-Après la mise en place du nouveau système, une erreur de compatibilité dans les transactions entre l'application Observo et InfSuite est appartue. Malgré les nombreuses étapes de tests, les anaylses préliminaires, la mise en place du système sur un serveur intermédiaire nommé staging qui est très similaire à l'environnement de production, le problème n'a pas pu être détécté avant. Il n'est survenu que lors de la mise en place des mises à jour sur le serveur de production.
+Après la mise en place du nouveau système, une erreur de compatibilité dans les transactions entre l'application Observo et InfSuite est apparue. Malgré les nombreuses étapes de tests, les anaylses préliminaires, la mise en place du système sur un serveur intermédiaire nommé staging qui est très similaire à l'environnement de production, le problème n'a pas pu être détécté avant. Il n'est survenu que lors de la mise en place des mises à jour sur le serveur de production.
 
 Le problème concernait une erreur de compatibilité avec les fameuses date lors de l'échange de données entre les deux application. La différence de format fournie par InfSuite n'était pas valide côté Observo, le système retrouvait donc la transaction en échec.