Skip to main content
Au lieu de faire les liens directement aux anciens éléments, et que ça puisse créer des problèmes de continuité, on va faire une banque d’anomalie en parallèle, et on fera la liaison entre la nouvelle anomalie et son entité dans la banque d’anomalie. Dans la logique ça se passe comme ça:
  • le premier rapport
    • toutes les anomalies sont nouvelles → on créer une anomalie dans la banque pour chacune
    • pas de création d’anomaly case automatique → doit se faire à chaque liaison
    • faire la comparaison avec les anomalies du rapport précédent et pas les anomaly case
  • Le deuxieme rapport
    • (encore à définir le process) on compare avec les anomalies de l’ancien rapport, et pour celle qu’il faut relier, on relie à l’élément dans la banque
Et pour tous les rapports suivant on fait la meme chose. Juste sur le process de comparaison, du coup c’est un peu plus compliqué, on va vouloir pouvoir comparer aussi d’autres anciens rapports. Process:
  • on récupère dans une liste les anomalies du rapport précédent
  • on détermine la liaison entre les nouvelles anomalies et les anciennes
  • ensuite pour les anomalies du nouveau rapport pas encore relié
  • on récupérer les anomalies des 3 - 10 rapports précédents (en fonction du total d’anomalie récupérée)
  • on fait la meme comparaison (probablement seulement pas IA, ou alors de recherche également, à voir)
  • et ensuite potentiellement une troisieme recherche
  • → si une anomalie n’as pas d’équivalent dans les anciens rapports, on va faire une recherche dans la banque d’anomalie pour voir les 3 anomalies avec la plus grande pertinence pour faire potentiellement une liaison
  • et si, on trouve vraiment rien (sous un seuil de niveau de confiance, ou vraiment aucun élement) → on créer un élément d’anomalie dans la banque
Dans la banque d’anomalie, les items ont :
  • un moyen de faire une recherche dessus (liste de mots clés, autre méthode à définir)
  • un titre, une description
  • les éléments filtrant (IT, unit / ou équipement)
Par contre pour savoir si une anomalie est persistante ou récurrente, on a plus cette notion là. Aujourd’hui on a un tag “nouveau” qui est calculé sur l’anomalie. si celle ci est la première occurence en date de l’élément relié de la banque d’anomalie, alors elle a le tag “nouveau”.

​
Ancien, ne pas prendre en compte

​
Réflexion

Piste écartée: avoir une anomalie liée à plusieurs rapport (complexifie grandement les relations entre les deux)

​
Affichage

Après comparaison des anomalies dans l’ancien et le nouveau rapport, afficher vue synthétique des éléments différents ou similaires, manquants, et dupliqués Laisser possibilité de lever une ancienne anomalie pendant le process ⇒ proposition d’automatisation des interventions Technique: previousAnomaly, previousLinkType

​
Cas chiant d’ajout de rapport

okay donc il faut que tu mettes à jour le plan. déjà sur la manière de faire -> on garde le lien unique entre les anomalies Ensuite il y a un cas qu’on a pas pris en compte, c’est le cas ou : on a poussé un rapport 2024 on a poussé un rapport 2026 le lien se fait entre 2026 et 2024 ensuite il pousse 2025 on voit qu’il veut lier avec le rapport 2024, qui est déjà relié avec 2026 Du coup, on le bloque il a du coup une modale qui lui affiche et lui propose de “remplacer” les liens (du coup si il fait l’action, on retire les liens 2026 vers 2024, et on lui permet du coup de faire les liens 2025 vers 2024)
Il y a 2 cas possibles un peu compliqué:
  • si pour une vérification dans une unité a plusieurs rapports passés actifs -> dans ce cas, on compare les nouvelles anomalies avec le cumulé des anomalies des anciens rapports actifs (relié par une intervention) (si le nouveau rapport est dans une intervention avec plusieurs rapports actifs sur une même unité d’une meme règle, il faut pas les comparer entre eux)
  • si une vérification passée regroupe plusieurs anomalies d’un rapport sur plusieurs règles et plusieurs unités, il faut simplement comparer les anomalies qui sont sur la meme it, et la meme unité.